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METHOD AND APPARATUS FOR SECURE CONTENT DELIVERY 
OVER BROADBAND ACCESS NETWORKS 

Related AppucATidNS 

This application claims priority to U.S. provisional patent application Serial 
Number 60/108,602 entitled, I^^ETHQD AND APPARATUS FOR SECURE 
CONTENT DELIVERY OVER BROADBAND ACCESS NETWORKS, filed November 
16. 1998 by Yonah Schmeldler, et al. 

In addition, this application claims priority to three commonly-owned U.S. 
patent applications, filed by the sartie inventors, Yonah Schmeidler. et al.. including: 

Serial No. 09/310.294. Attomey Docket No. A0028/7000, by Yonah 
Schmeldler. et al., entitled "METHOD AND APPARATUS FOR SECURE CONTENT 
DELIVERY OVER BROADBAND ACCESS NETWORKS" . filed on May 12 , 1999; 

Serial No. 09/31 1 ,923, Attomey Docket No. A0028/7001 . by Yonah 
Schmeidler. et al., entitled "METHOD AND APPARATUS FOR INSTALLATION 

ABSTRACTION IN A SECURE CONTENT DELIVERY SYSTEM", filed on May 12 . 
1999: 

Serial No. 09/31 0,299. Attomey Docket No. A0028/7002, by Yonah 
Schmeidler, et al., entitled "METHOD AND APPARATUS FOR CONTENT 
PROTECTION IN A SECURE CONTENT DELIVERY" , filed on May 12 . 1999; and 

Serial No. 09/439,906, Attomey Docket No, A0028/7003, by Yonah 
Schmeidler, et al., entitled "METHOD AND APPARATUS FOR ON-DEMAND 
DISTRIBUTION OF CONTENT OVER BROADBAND ACCESS NETWORKS" . filed 
ori Nbvembi^r121, 'i999. , ^ / 

The subject matters of th6 abdvi^id^iirtified cbpisncling patent applications are 
incdipdrated herein by this ref^^ 

Field 6f THE Invention 
this Invention relates generally to a method and system fdr distributiori 
across networits, and. more specifically to a system for delivering executable 
sbftware content over broadband access networi^s In a secure manner that enables 
oiHiemand subscription. 

1 
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Background dp THE iNvtN^^^ 

The on-demand delivery of software applications and muttimiedia data types 
such as audio, video, animation, etc. has hot beeri practical until recently primarily 
5 due to the rates at which data is transmitted across cbninniunication networks. The 
rate at which data, formatted into a series of bits, is transmitted is refenred to as a bit 
per second (bps). Early modems were capable of transmitting infonmation at a rate 
of approximately 300 bits per second. Thereafter, the speeds at which modems 
were capable of transmitting and receiving data increased. With such increases in 

10 modem speed, the nature of network topologies as well as the types of data 

transmitted across networks began to evolve. With modem speeds of 9600 bps and 
1 200 bps computer networks such as the Internet were primarily an ASCII text 
environment with specific protocols and text messaging. Subsequent increases in 
modem speed enabled more complex information to be accessed over the Internet 

15 and other computer networks. While ASCII text paradigm still exist on the World 
Wide Web portion of the Internet today, the more recent increased bandwidth 
environment has enabled communication of more complex content and multimedia 
datatypes. 

More recently, high performance broadband technology and cable modems, 
20 with connectivity speeds in excess of I ri^^^^^^ 

by cable, telephone, cellular and satellite enterprises Worldwide. Curent broadband 
access networks include the cable industry's shiared medium Hybrid Fiber Coax 
(HFC) networks and the telephone industry's digitiai^ 

With the advent of broadband technology brdadbarid access hetWdrkis^ 
'■ ■25" ;cbirtilf)liex multe 

Conhpact Disc Read Only Memory (CD-ROM) and Digital Versatile Disc (DVD), 
hereafter refen-ed to as litle(s)," are now capable of being remotely accessed by 
subscribers to brdiadband access network services. 
There are, however, factors other thah data ra^^^ 
3() demand delivery of titles impractical. One jsuch obstacle preventing on-demand 
deliveiy of content including software and multinie^^^ 

requirement to have the title loaded onto the stibscriber's local computer system In 
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order to execute the title. Further, the widespread copying or "pirating" of title 
content, arid the associated security risks associated with distribution of fully enabled 
copies of titles, has made on-demand distribution unattractive to software publishers 
and content libraries. 

5 Accordingly, a need exists for a method and system for on-demand delivery of 

executable software content, which does not require installation of the content on the 
subscriber's local computer system. 

An additional need exists for a method and system to deliver content to 
subscriber's in an bn-denriand basis which provides security to protect the value of 
10 the content and which prevents uhauthdrized use iand copyih 

An additional need exists for a method and system in which content may be 
delivered across broadband access network in a mariner which meets the latency 
requirements of the conterit being executed. 

15 Summary OF THE INVENTION 

The Secure Content Delivery Platform (SGDP) of the present invents 
delivers high-bahdwidth executable content, on-demand, over broadband access 
networi<s. Using the SCDP platform, broadband subscribers, e.g. subscribers to 
cable modem and xDSL services, have access to titles across the broadbahd 

20 nietworks. 

Users select a title to run from a viflual stbrefroht, for example on the Worid 
Wide Web, which contains a virtual cataldg of available titles. Upon selection of the 
title - the user nego^^ adual parch^s^^^^^ 

reigjistratibfi witti athlrd party elebtib^ 

; 25 user billing infbnfrtatiort, and seledioh of drib of the puifchase types offered With i^^^ ■ 
selected title. Examples of possible purchase types may include 1) a ti^^ 
demo of the title, 2) a single payment for a single use" of a title, 3) a 
which allows unlimited "usies" 61 a title over some specified time peribd e.g.. week, 
•••mohth.etc. • 'r'[^\\^ . - ■ ;'-';-V."- 

30 Upon completion ofthe purchase negotiation, SCOP dient software mn^ 

on the user's PC obtains ah authorization token and keying material from a 
Conditional Access Server (CAS). The token authorizes the client process to run the 

- 3 * 
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selected title from a network file sierver accessible across the broadband network. 
The data retrieved from the file server Is encrypted. The SCDP client process uses 
the keying material provided by th^ cdhditional access server to decrypt the data 
from the file server. VVIth the present invientioh. titles run on the user's PC, but the 
5 titleisn6tdownlojaded;initsehtjre^^^^ 

electronic package that contairis the title's fllds in a compressed and encrypted form, 
referred to hereafter as a briq. The briq is actually a portable, self-contained file 
system, containing all of the files necessary to run a particular title. Briqs are stored 
on a networic file server, refen-ed to hereafter as a RAFT server, accessible across a 

10 broadband networic. The SCDP client treats the briq like a local file system on the 
user's PC. When running a title, the operating system, e.g. Windows, makes read 
requests to this local file system. The SCDP client, which, in the illustrative 
embodiment, includes a Windows Virtual Device Driver (VxD), services these 
requests by retrieving the requested blocks of briq data from, the RAFT server. After 

15 retrieving the requested block of data, the VxD decompresses and decrypts the briq 
data, and passes the data onto the bperatirig system on the user's PC. 

In accordance with one aspect of the present invention, the software title is 
never Installed" on the target system. The SCDP client software creates an 
installation abstraction, maintaining the illusion for the operating system that the title 
: _ 20 currently executing is installed on the hbst PC. Thus, when execution of the title is 
terminated, there is no remaining evidence the title ran on the system. No files 
associated with the title are left on the PC's HardKlrive, and no operating syste 

■ V • S d^sirable to 

26 ) rhaintaih across inlays; e:g.; t^^^ 

informatlbrirtiayl^ 

: In aio^ 
software uies an inv^nfrve p^^ 

protocol to retrieve bri(^ data across brtiadb^irid h The protocol provides 
30 SCDP clients with read<inly access t 
Becausfe tile briq is treated iike a 1^^^ 
; be visible as an operating system^^^ 
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operating system's file system manager, the Windows Installable File System (IFS) 
Manager in the illustrative enibodiment. As a result, the RAFT client file system 
driver, a VxD in the illustrative embc)diment. is smaller and simpler than a remote or 
network file system driver. In addition, the RAFT protocol supports dynamic 
5 bandwidth restrictions .e.g., "bandwidth throttling", and access control through the 
use of RAFT authorization tokens. 

In accordance with another aspect of the present invention, the SCDP 
employs a variety of security mechanisms to protect content from unauthorized 
access and replay. Authorization tokens and decryption keys are obtained from a 

10 conditional access server. Network communication between an SCDP client and 
CAS is protected via a secure remote procedure call (RPC) interface. Once a 
secure channel is established between SCDP client and CAS. the SCDP client 
requests a RAFT authorization token and keying material for the selected title. The 
authorization token is a signed message from the CAS indicating that the requesting 

15 user can have access to a specified briq. on a specific RAFT file server, for the 
length of time spelled out in the negotiated payment type. 

While the RAFT authorization token gives an SCDP client access to a title's 
' briq. the SCDP client must still unpack, e.g. decompress and decrypt, the briq to gain 
access to the title's file data. The CAS provides the user with the keying material 

20 necessary to decrypt briq data, however, the CAS does not directly provide the 
SCDP client with keying material. Insteiad, the CAS hides keying material from this 
user by embedding the keys in obfuscated bytecode that implements the decryption 
algbrithm. Rather than delivering isolated keying^ riiaterial to the SCDP client, the 
CAS deiiveit obftjsdated b^ecode, rie^ferired to hereafter as ah activiator. the 6CDP 

25 client's^^^^v^^^ 

bytecode Interpreter. Code obfuscatibh hiakes the activator difTicult to reve^^ 
erigineeir, requiring a hacker to spend significant time and resources to extract the 
keying material from the activator, at a cbst typically greater than the value of the 
content being protected. With the' cbntemjslated invention, activators are unique per 
30 client, per briq, per execution, i.e., each activator obtained from the CAS is different 
and usable for one time only thereby preventing the leveraging of a single, costly 
reVetse engineering effort oiit to multiple users. 
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In accordance with the present invention, both the RAFT authentication 
tokens arid activators have a limited lifetime. Authorization tokens indude an 
expiratfoh time, after which they are no longer valid. A mnhing activator, at a certain 
point, Initiates an exchange with this CAS to refresh itself. If the exchange is 
unsuccessful, the acBviator becomes Inoperable and the title inoperable. The 
refreshing of activators is referfed to hereinafter as activator keepalives. The 
keepalive medianism results in the delivery of an update to the currently mnning 
activator, which may include new keys, data, or even code. Authorization token 
refresh accompanies activator refresh. A new authorization token, along with the 
decryption keying data, is embedd^ within the new activator. At startup, the 
refreshed activator delivers a new RAFT authentication token to the RAFT VxD 
within the SCDP dient. 

SCDP system is media independent and will operate across any broadband 
neftvori<ing technology, induding HFG networi<s and the telephone industry's digital 
subscriber lines, provided sufficient bandwidth exists between the user and networi< 
file servers to satisfy the latency requirements of the cun-ently executing CD title. 
The SCDP system may also be implemfented using 1 0 Mbps and 1 00Mbps Ethemet 
Local Area Networks, for example within enterprise networics to deliver executable 
content over intranets as well. 

According to a first embodiment of the invention, a method for securely 
delivering content over a networi< comprises the steps of: (a) storing at least one title 
on a content server operatively coupled to the networic, the title stored in 
unexecutable fonTif{b) storing on an adiesis si^rveropera^^^ 
netWdrkaldcaiib 

e^sciiteW^ the rietv*orkt6 

obtain the location idehtifi^rbf the title from the access sewer prior to retrieving at 
least a jjortioh of the title fiibm thfe content serVef; aiid (d) requiring a dient process 
to obtain from the access serverttie date necessary to process the portion of the title 
•into execufeble form. 

According to a second embodiment of the iriventidn, an apparaftjs for secure 
delivery of over a networic comprises: (a) a content server operatively coupled to the 
rietvvorit and having at least one title stored therein unexecutable form; (b) an access 
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server operatively coupled to the netvvork and having stored therein a location 
identifier of the tit|e and data necessary to process the title into executable form; and 
(c) a client system operatively coupled to the: network and containing program logic 
configured to obtain from the accbss server the location identifier of the title and the 
5 data necessary tb process the portion of the title into executable form. 

According to a ttiird erribodiment of the invention, an apparatus for secure 
delivery of title content over a network comprises: (A) a content server system 
connectable to the network, the content server system comprising: (A.1 ) 
authentication logic, responsive to a token received from a client process, the token 

10 containing data identifying a time period and configured to detennine whether the 
client process is authorized to access a title at a specific time, and (A.2) access 
logic, responsive to the token received from the client process, the token containing 
data uniquely identifying one of the titles stored in the memory, for enabling access 
to the memory and the title uniquely identified by the token; (B) an access server 

15 system connectable to the network, the access server system comprising: (B.I) 
cbnvefsion logic, responsive to a uhicjue identifier of a title supplied by a client 
process and configured to convert the unique identifier of the title into a location 
identifier indicating an address on the network where the title may be accessed, and 
{B.2) activator generation logic responsive to a request from a client process and 

20 configured to generate an activator in response thereto; and (C) a client system 
connectable to the hetwdri<, the client systenh comprising: (C. 1 ) progranfi logic 
configured to obtain from the access sen/er a token, an activator and a location 
identifier of the content s;e^^^^^^ can be accessed, (C.2) 

: : : ^ ^ prp^ 

25 sery^r\ ^dJ (a3) pro^ configured ^ 6xfecut^ th6 portion of the titfe 

' retrieved fitirn the content server, ; 
According to a fourth embodiment of the 
application on a local computer systeni without the application being Installed on the 
local cohriputer system, the rtethbd comprises: (a) accessing a networic mbuntable 
sd file system and set of reigistry entries related to the appiicatfon; (b) mounting the 
rietworic fil6 syst6Fh; (c) storing the registry entries on the local computer system; (c) 
retrieving at least a portion bf the afiplication from a remote source; (d) executing the 
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application under th6 control of an operating system on the local computer system; 
(e) Intercepting requests from the operating system: and (f) redirecting selected of 
the intercepted requests to the registry entries stored on the local computer systerri. 
According to a fifth embodiment of the invention, an apparatus for executing 
5 an application without installing the application on the computer system coitiprises: 
program logic configured to mount a netwdrk fife system and store in the memory a 
plurality of registry entries related to the application; program logic configured to 
execute at least a portion of the applicatidn retrieved from a remote source; and 
program logic, responsive to requests from the operating system, and configured to 

10 Intercept requests from the operating systeni arttJ redirect selected of the Intercepted 
requests to the set of registry entries. 

According to a sixth embodiment of the invention, a method for enabling on- 
demand delivery of a title comprises: (a) obtaining from the access sen/er a token, 
an activator and a network address of a source at which an identified title can be 

15 accessed; (b) transmitting the token to the source, the token data defining an 

interval of time in which the source may be accessed; (c) retrieving at least a portion 
of the title from the source; (d) executing the portion of the title received from the 
source; and (e) obtaining from the access server a refreshed token. 

According to a seventh embodiment of the Invention, a method for enabling 

20 requesting processes to access a title comprises: (a) authenticating a launch string 
from a requesting process; (b) converting a unique identifier of a title received from a 
requesting process to a location identifier indicating an address on tiie computer 
networi< where the title may be aiccessed: (c) Qerierating an activaton and (d) 
fdnwattling the activator to ttie reiiues^^^ 

25 According to a elghtii embbdirheitt of t^^^^^^ in a server apparatijs 

comprising a processor, memory and a netWbri< Jntierface, the server apparatus 
conrtectable to one or more dient processes a 

comprises: (a) receiving a token from a client pifocess through the networit Interface, 
the token containing data identifying a time>eriod arid data uniquely identiiying a 
30 titie; (b) detemilning whether tiie dient process Is aiithdrized to access the titie at a 
specific time; (c) If the dient is auttiorized in step (b). accessing tiie memory arid a 
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title uniquely identified by the token; and (d) supplying to the client at least a portion 
of the title Identified by the token. 

According to a ninth embodiment of the invention, a the method for selectively 
enabling delivery of a title over a computer network to one or more requestor 
processes comprises: (a) providing, under predetermined conditions, a requestor 
process with access to selected portions of a title, the title being stored at an 
address on the computer network in unexecutable forni; (b) providing the requestor 
process with data useful in processing the title from unexecutable form to executable 
form; and (c) allowing execution of selected portions of the title on the computer 
system while preventing the title from being installed on the computer. 

According to a tenth embodiment of the invention, a method for delivering 
titles over a computer network to one or more requestor processes comprises: (a), 
receiving from a requestor process data identifying a title; (b) providing the requestor 
process with data identifying a location on the computer network where the title 
executables may be accessed and authorization data necessary to access the title; 
and (c) receiving payment infpnnation from th6 requestor process^ 

According to an elevenilh embddlnrient of the Invention, computer program 
product for use with a computer system operatively coupled over a corriputer 
network to one or more requestor processes, the computer program product 
comprising a computer usable mediunri having program cod^ stored thereon 
comprising: (a) program code corifigured to recelve from a requestor process 
coupled to the network data identifying a selected title; (b) program code configured 
to revive payrnent infomiiation from the requestor process; (c) program code 
cohfigur^ to eriable tho requestor pirbCes^ to access iseiected pbrtibrls of th^ title for 
ddwnldading; and (d) program code rort^unid to ^lldW ekectitioh of the tiUe 
coniputer system while preventing in^tallatibri df thi title thereon. 

BMEKDESCRIPtlON OP ti^E Di^WlNGis 

w •■ ■ ' ■ ■ • ■ ' ■ ■ ' ' :■ 

The above and other features. objects arid advantages of the invention will be 
better understood by referring to the fbllowlrig detailed description in conjunction with 
the accompanying drawing In which: 
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Figure 1 is a block diagram of a Gomputer system suitable for use with the 
priBsent invention; 

Figure 2A is a conceptual block diagram of a broadband network in which the 
secure content delivery system of the presiBht invention may be implemented; 
5 Figure 2B is a conceptual block diagram illustrating the elements of the 

inventive system and the interaction with other network elements in accordance with 
the present invention; 

Figure 3A is a conceptual block diagram of the SCDP client in accordance 
with the present invention; 
10 Figure 3B is a conceptual block diagram of the launcher module of the SCDP 

client of Figure 3A; 

Figure 3C is a conceptual block diagram of the ARFS VxD module of the 
SCDP client of Figure 3A; 

Figure 3D is a conceptual block diagram of the RAFT VxD module of the 
15 SCDP client of Figure 3D; 

Figures 4A-B collective form a fl^^ 
subscribing to content and launching a title In accbrdance with the present invention; 

Figures 5A-C collectively font! a iflbw chart illust 
performed by the SCDP client in aocortlanGe with the present invention; 
20 Figures 6 Is a flowchart illustratiriig the prbces^ executed by the SCDP client 

componefhts in aixordance with the pre^nt i^^^ 

Figuris TA is a conceptual dia^^^ 
the present invention; 

^^^^^^^^^ ai fkw^ executed by ihe GAS seri^ier in 

Figure 8 is a conceptual diagram b^^ 
jfiresent invention; 

Figure 9 is a conceptual dia^^ 
present inv^rt^^ 

36 Figure 10 is a conceptual diagrarti of the RAFT server of F^ig. 2 in accordance 

with the present invention; 
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Figure 1 1 is a conceptual diagram of a RAFT packet header in accordance 
with the present invention; 

Figure 12 is a conceptual diagr^rn of a briq data package in accordance with 
the preseht invention; 

5 Figure 1 3 Is a cdhceptuai block diagram of ian activator in accordance with the 

present invehtibri; and 

Figure 14 is a conceptual block diagram of an eConfimerce service in 
acconJance with the preseht invention. 

10 Detailed DESdRiPTiON 

Figure 1 illustrates the system architecture for a computer system 100 such 
as a Sun SparcStation 5 workstation, commercially available from Sun Microsystems 
of Palo Alto. CA, or ah IBM RS/600d workstaioh or IBM Aptiva PC, both 
commercialiy available frbrh Intierhational Business Miachlnes Corp. of Amiohk, NY. 

15 on which the invention may be implemented, the exemplary computer system of 
Figure 1 is for desGriptive purposes only! Alihoujgh the descrlptioh may refer to 
terms oommbniy used in idescribinig particular computer systems, the description and 
conceptis equally apply to other syistenrl^i ihcludihg systems having architectures 
dissimilar to Figure 1. 

20 Computer system 100 includes a central pfbcessing unit (CPU) 105, which 

may be implemented with a convehtiohaj microprocessor, a random access memory 
(RAM) 1 10 for temporary storage of ihfontiate^^^ arid a read only memory (ROM) 115 
^ for peHhfi^^ of ihioriTfl|itiS 120 is provided for 

•:^":-\^c6htit)l^^^^ - ' " 

^25 ; ' : \ A A bus 

cohtrdlier 125 is provided for controlling bus i 30. An interrupt controller 135 is used 
for receiving arid processing various iritenupt signals from the system components. 

Mass stofBge may be provided by diskette 142, CD ROM 147, or hard drive 
1 52. Data dnd software miay be exchanged with computer system 1 00 via 

30 . removable media such as diskette 142 arid CD ROM 147. Diskette 142 is insertable 
into diskette drive 141 which is, in turil, connected to bus 30 by a controller 140. 
Sirhilariy, CD ROM 147 is insertable into CD R^^ 146 which is. in turn. 
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connected to bus 130 by controller 145. Hard disk 152 is part of a fixed disk drive 
151 which is connected to bus 130 by cbhtroller 150. 

User input to computer system 100 niay be provided by a number of devices. 
For example, a keyboard 1 56 and mouse 1 57 are connected to bus 1 30 by controller 
5 155. An audio transducer 196, which may act as both a microphone and a speaker, 
is connected to bus 130 by audio controller 197. as illustrated. It will be obvious to 
those reasonably skilled In the art that other input devices, such as a pen and/or 
tabloid may be connected to bus 1 30 and an appropriate controller and software, as 
required. DMA controller 1 60 is provided for performing direct memory access to 

10 RAM 110. A visual display is generated by video controller 165 which controls video 
display 170. Computer system 100 also includes a communications adapter 190 ' 
which allows the system to be interconnected to a local area network (LAN) or a 
wide area network (WAN), schematically illustrated by bus 1 91 and network 1 95. 
Operation of computer system 1 00 is generally controlled and coordinated by 

1 5 operating system software, such Windows 95 or Windows NT®, commercially 
available from Microsoft Corp., Redmond, WA. The operating system controls 
allocation of system resources and perfonns tasks such as processing scheduling, 
memory management, networking, and I/O services, among things. In particular, an 
operating system resident in system memory and mnning on CPU 1 05 coordinates 

20 the operation of the other elements of computer system 1 00. The present invention 
may be implemented with any nunfiber of conimercialiy available operating systems 
including OS/2®, UNIX®, Linux and Solaris®, among others. One or more browsers 
applications such as Netscape Navigator, Version 2.0 and thereafter commercially 
ayailable from Netscape Cbm^ and Internet Explorer, 

; <25 ^/erei6n 1.0 and thereafter, cbrhmercially a^^^ 

Rednibhd, Washington, ntay execute uhcler the control of the operating s^tem . 

SCDP System Overview 

F^lgUre 2A illustrates conceptually the main cdmpdnehts of a Secure Cot^ 
30 Delivery Platfonn (SCDP) system 200 in accordance with the present invention, as 
well as other elements in a broadband network environriient, such environment 
being for exemplary purposes only and hot to be considered limiting. The elements 
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illustrated in Fig. 2A are to facilitate and understanding of the invention. Not every 
element illustrated in Fig; 2A or describiecl hereiri is necessary for the implementation 
or operation of the invention. As illustrated In Fig. 2A, SCDP system 200 comprises 
a Conditional Access Server (CAS) 210, an associated CAS database 212, a 
Random Access File Transfer Server (RAFT) 206, a RAFT database 208 and SCDP 
client 216. 

In addition to^CAS Server 210, RAFT Server 206 and SCDP Client 216, the 
present invention contemplates use of a virtual store front 215 and eCommerce 
Server 202. eCommerce seryer 202 bias an accompanying billing database 204. 
Store front 215 has an accompanying database 213. In the illustrative embodiment, 
servers 202, 210 and 215 are connected over a private, secure local area network 
(LAN), such as a local ethemet network. The LAN is, in turn, is connected to a 
global computer network topology, illustrated as internet cloud 240 in Fig. 2A, by an 
Internet service provider (ISP) 230. Any number of commercially available internet 
access service providers such as MCl WoridCom, AT&T, America OnLine, etc. may 
be used as ISP 230. In the illustrative embodiment, although servers 202, 210 and 
215 are illustrated as being connected through a private local area network, it will be 
obvious to those skilled in the arts that such sen/ers may be operatively coupled over 
other non-private networks. Such as the Internet. In addition, eCommerce server 
202 may be coupled to a credit processing server of a financial or banking institution 
(not shown) to assist in processing of credit card and/or other types of transactions. 

Referring again to Fig. 2A, one or more client PCs having an architecture 
similar to that Of Fig. 1, are connected to the SCDP system 200 over a broadband 
access network 203 and cable provider 207; In the jllustf^iWe embodlrheht, a cable 
modem (CM) conhects to the hdst.PC bn Which the SdDP dient is exedutirig. In tiifn, 
a plurality of cable moderhs are coupled to a cable node via a high frequency 
connection. Typically, as many as 1 .000 host PCs may be connected. to a cable 
node through appropriate cable mddenfc and high frequency connections. Each 
cebie node is. In turn, connected through a cable modem tennlnation system 
(GMTS). A Plurality of cable modem tennination systems are coupled to a 
tenninatioh headend. A plurality of interconnected headends comprise the backbone 
of the broadband access network. The cable h^dends are typically tocated at the 

■ 13 
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cable company facilities and may include a host data temiinal connected to an 
Internet Protocol (IP) network through a T1 line or other connection. The T1 line, 
may be, in turn, connected to the Internet through an Ihtemet Service Provider (ISP) 
230. RAFT server 206 and its acconipanying database 208 are coupled ito the 
5 broadband access network 203 l)elween the Intemet Service Provider 230 and the 
host data tenninatfon facility or head end provided by the cable company. In this 
manner, the RAFT Server 206, although part of the SCDP System 200, Is located 
remotely from the CAS 210, eCorhmercie Server 202. and virtual store front 215. 
The cable modem temiination system 209 converts high frequency data from a cable 

10 infrastructure into Internet Protocol format u^ing the published Data Over Cable 
Service Industry Standard (DOCSIS). 

Alternatively, a client PC may be connected to SCDP system 200 via a digital 
subscriber line (DSL) service, as illustrated in Fig. 2A. In this configuration, a host 
computer on which the SCDP client is executing is coupled tp a telephone company 

15 switch via a DSL modem and existing public switch telephone network infrastructure. 

The constmction of DSL subscriber networks and broadband access networks 
are known in the art and are currently used by cable companies and telephone 
companies extensively and will not be described in further detail here for the sake of 
brevity. Accordingly, not every element of the above described systems is illustrated 

20 In Fig. 2A. 

Subscription Process 
Figure 2B illustrates conceptuaily the interaction of the components within the 
SCDP system 200. The flowchart of Figs. 4A-B iri cbn^^^^ 
block diagram of Fig. 2B illustrates the procedural by the SCDP 

25 isystem 200 during the subscrt^^^ lauhdi pmic^ss^^^^ with the 

present jnventipfi. 

A user equipped with the SCDF^ client 21 
browser e.g., Netscape Navigator or Mlcrd^^ 

thie virtual storefront 21 5, as illustrated by step 401 . On the storefront 21 5, 6ach 
30 available title is posted ias a digital offer embeddieid within a Unrversal Resource 
Locator (URL). The digital offer contains irifdhnnatipn identifying the selected title and 
purchase type. Selecting the digital offer directs the isubscribers browser to the 
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HTTP front-end 202A of the eComfnerce server 202, as illustrated by step 402. The 
user negotiates with the eCommerce server 202 for a purchase based on the 
information in the digital offer URL. as illustrated by step 403. The negotiation may 
typically involve user registration and the provision of credit infonmatioh. 
5 The eCommerce server generates a launch string, containing the information 

identifying and authorizing the purchase, including a Universal Resource Name 
(URN) uniquely identifying the desired content, as illustrated by step 404A. The 
format and description of the URN and launch string are described hereinafter. The 
launch string is digitally signed by the CAS 210 and provided to the eCommerce 

.10 . seirvice 205 for delivery to the SCDP client 21 6. as illustrated by step 404B. 

The launch string is wrapped with a MIME (Multipurpose Internet Mail 
Extension) header. When the launch string is received by the SCDP client's browser 
224, the MIME type associated with the launch string is located in a registry entry, 
which results in the invocation of the launcher module 220 within the SCDP clierit 

15 21 6, as illustrated by step 405. The Launcher 220 establishes a secure RPC 

connection with the CAS 210 and requests that CAS provide a URL for the specified 
URN , i.e. a URN to URL conversion, as illuistrated by step 406A. The URL identifies 
thei Ideation of the corf eispoHdirig briq data. The CAS 210 fdnwards the 
cbfrespohding URL to the Launcher 2^0. Once the Launcher has Identified the 

io location of the correspontling briq data, the Launcher sends a purchase request to 
the CAS; the purchase request including thei Launch string, as illustrated by step 
406B. 

; iTie CA^ y$n^^s the launch ^tHrig^s sigrisrtur^, and then returns a RAFT 
C • ; a The 
25 ^ctiv^tbr iand autHbrizatibn toteh are described hereafter in greater detail. The 
authbriziationtb^^ Next, the 

Launcher lauriches the title by passing the activator to the ARFSD VkD 21 8, as 
f ■ ? iliustrateid by step 408. The ARFSD VkD runs the activator which passes the RAFT 
V a^^ the RAff VkD^2; The ftAFT VxD opens the URL and reads 

: 3d the header, as illustrated by step 409. the RAFT VxD sends the liiitial authorizatibn 
token to thb RAFTSeiye^ as illustrated by step 410. The RAFT VxD 222 starts 
reading content from RAFT server 206, passing the received content back to the 
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ARFSp VxD 218. as illustrated by step 411. the ARFSD VxD uses the activator to 

decrypt and decpnhjiress the content in the fomi of briq data, and perfomi integrity 

checWng on the blocks of decrypted data, as illustrated by step 412. 
thweafter, the opierating systerh executes the 
5 preselnted by ARFSD VxDi as illtistRBited by ste^^^^^ 

reiquests the launcher 220 to ask the CAS 210 to refresh the activator and the ftAFT 

authorization token. UpOh the first of such requests, the CAS posts the purchase to 

thiB 6Cpnrirnerce server 202 for trartsactiorisetli^^ 

The lifetime of the first activator may be on the order of minutes, Successful 
10 activator refresh after the first timeout Serves as an indication tiiat the title is running 

successfully. . 

Having provided an overview of the system components and their interaction, 
a moire detailed description of the inventive secure content delivery system 200 and 
the processes perfomied thereby are set forth with reference, to Figs. 3A-14 and their 
15 accompanying explanations. 

SCDP Client 

Refening to Fig. 3A, a conceptual block diagram Of the SCDP client 21 6 in . 
accbnJance witii the present invehtidh is illustrated. The SCDP client 216 allows 
users to njn briq-encoded titles oh a host P^ 

client comprises Launchier 220, Arepa File System Driver VxD (ARFSD VxD) 21 8, 
arid RAFT Client VxD 222. The SCDP client 21 6 niay be Implemented as an 
application executable dri operatlri^ 
tite iilustratiori eh^^ 
althitiec*ure; sui^ as an iSM 

reference to Fig. 1. In additidh tp:Sdfif^ dierit 216, a brdwser 217, typically ah 
Html browser such as NetScape Navigator dr Mlcfdsoft Exploreir. may also be 
running Uhder the cdritrol of operating system 
arid RAR VxD 222 are ddscribe^ 
respec^vely; 

Figure 3B illustiates Cdnceptually a bidck diagram^ 
modules comprising Laundier 220 of ^CDP dieht 216. Spedficaily, La 
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comprises a control module 300. a CAS RPC library 302, a ARFSD VxD 
communication llbraiy 304 and a user Interface 306. In the illustrative embodiment, 
the launcher 220 may be implemented as a Windows applicatiori containing logic 
whibh coordinates all communicatidn betweeh the SCDP client and the CAS 204. 
The Launcher 220 is invoked by the cliefit's web browser i217, upon completion of 
purchase negotlsition with the eCommerce system 202. The eCommerce system 
delivers the dlent web browser a launch string with MIME type associated with the 
Launcher! In addition, the Launcher manages ail communications with the CAS, 
including 1) obtaining from the CAS the address of the RAFT server and the briq 
path name conresponding to the selected title; 2) obtaining from the CAS a RAFT 
authorization tol(en and activator necessary to retrieve briq data from the RAFT 
server and to decrypt the retrieved data; and 3) asking the CAS to refresh the RAFT 
authorization token and the activator. 

To facilitate communication between the CAS server 206 and the ARFSD 
VxD module 218. Launcher 220 includes CAS RPC Library 302. which may be 
implemented as a series of objects or program code which generate and receive 
communications to/from the CAS server 206 through a reniiote procedure call (RPC) 
library. One such RPC library suitable for use as module 302 is the NobleNet 
Secure RPC Product commercially available from Noblenet, Inc. Optionally, a 
network transport product, such as those adhering to the Secure Socket Library 
(SSL) standard published by Netscape Communications Corporation, rriay be used 
to transport the RPC calls across the fieti\rori< and thereby further enhance the 
security of transrhisslbris to/from the SCDP client in the inveotrve system. . A 
Cdmiriuhit^ition is also utilized fer comrtiuhicetldhs between the launcher 
module 220 aridlhe ArFSD VxD liiodule 218 and betw^h ARFSt) Vxb.mbdiiie 2?i8 
• irid RAFT Vxb 222. Such library again iridudes ctode pi- bbjects nelcesisary to 
cohifnuniciate data between the Launcher 220 sind the VxD 218. For exarnple, as 
deiscribed jn greater detail hereinafter, selected information frorn the briq header 
1202 of briq 12Q0, as illustreted in Fig. 12, is read by the control module 300 arid 
supplied to VxD 218 through the communication library 304, during execution of a 
title. A 
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Upon invocation of launcher 220. a grapliic user interface (GUI) is presented 
to a user through user interface 306. In the illustrative embodiment, user interface 
306 includes the appropriate program logic and/or objects necessary to interface 
with the operating system interface and application program Interfaces (APIs) 
5 contained within the Windows operating system in order to render windows, present 
graphic infommation within such wihdovys, and receive corhmands from a uservia a 
keyboard, mouse or other pointing device, such user interface being well within the 
scope of those reasdriably skilled in the art. Thraugh this GUI, the user may set user 
preferences, e.g., disk cache size, and be notified of en'or conditions. 

10 Control module 300 may be implernented with the appropriate code or objects 

to carry out the algorithm necessaiy to launch a title and continue communications 
between the SCDP client 200 and the CAS 210 and the RAFT server 206. More 
specifically, the algorithms executed by control module 300 are illustrated in greater 
detail in Figs. 4A-6 and their accompanying descriptions. 

is Figure 30 is a conceptual block diagram of the ARFSD VxD 304 of Fig. 3B, 

VxD 304 comprises a byte code interpreter 308. a control module 310 and a ARFSD 
VxD communication library 312. The ARFSD VxD 304 is a virtual device driver 
enables the operating system to read the briq data as a local file system. ARFSD 
VxD 304 decompresses and decrypts briq data. In addition. ARFSD VxD maintains 

20 the installation abstraction, e.g., supplying Windows registry information. The 
ARFSD VxD implements dynamic registry entries by intercepting all operating 
system registry access calls and then simulating registry entries that arie associated 
with the running title, but not saved on disk. 

25 AbtivatorsandtheBytecodelnteri^^ 

As described previously, the activator 228^ 6^^ 
interpreter 308 embodied in the ARFSD VxD 304. The activsitor represents a portion 
of the SCDP client software which is obtained from the CAS 210, and, which the 
ARFSD VxD 304 employs to decrypt biiq data. The form and content of the activator 

30 as described in greater detail with reference to Fig. 13. Activators implement a 

kieepalive mechanism that requires the activators to pieriodically ask the CAS 21 0 for 
replacement activators. Thus, cbmrriunicatioh with the CAS must be riiaintained in 
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order continue running of a title. In the Illustrative embodiment, the keepalive 
mechanism within activator 228 may be implemented as a numeric string or as 
othehvise described with reference to Fig. 13. 

The activator is implemented as a dynamic bytecode object that can be run 
5 within the ARFSD VxD 304. The CAS generates activators through calling the 
activator generation routines which may be resident in an external library, as 
previously described with reference to Activator Factory module 710 of Fig. 7. The 
RAFT token, discussed above, is packaged with the activator. The activator 
eventually will time out, after which the SCDP client 21 6 must call the CAS and * 

10 request a new activator. The life of the activator is detemnined by the start tirne and 
end time data values contained within the token portion of the activator. 

The SCDP system 200 uses activators to protect the release of cryptographic 
material to the SCDP client 216. An activator may be implemented as a piece of 
obfuscated bytecode that is run inside the ARFS VxD 304 and enables decryption of 

15 a briq. Once the activator is downloaded, it may make further RPCs to the CAS 21 0 
to finalize the delivery of the keying material. Code obfuscation within the activator 
may protect against extracting the keys. 

The illustrative implementation of activators also utilizes remote execution to 
protect keys in the activator. Remote execution makes the activator incomplete, i.e. 

20 gives the activator enough infonnation to continue operation for a limited period of 
time and then requires the activator to requiest further code or data. The bytecode 
interpreter 308 within the ARFiSD VxD 304 comprises program logic, code or objects 
which extract the cryptographic key data from the activator. In the illustrative 
embodimenti the activator rriay have thfe format and content as described with 

25 reference to Fig.1 3. 

In alternative embodiments, which ufi^^^^ 
implementations In which the activator contains obfuscated bytecodes. the bytecode 
interpreter 308 within the ARFSD VxD 304 may be implemented with a rich 
instruction set, to increase the opportunities for simple obfuscation. Note that there 

30 are no traditional limits of hardwiare inrtpieniented microprocessor instruction sets, 
and thus many bits for addressing modes and instmction formats can be used. The 
complexity and secrecy of such instruction set allows secure delivery content within 
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the SCDP systems Since the bytecode rtins inside a VxD. the bytecode interpreter 
308 may call exported interfaces from other VxDs but does not need to call WIN32 
functions from the operating system or handle DLLs. 

Byte code interpreter 308, in the illiiistnative embodiment, is implemented as a 
virtual machine having the appropriate code and/or pipogram logic necessary to 
interpret and execute the byte codes contained within an activator received frorti the 
CAS 210. Such a virtual machine includes the appropriate routes to interpret the 
byte cbde(s), store any temporary data from the byte code stream, and execute the 
processes identified by the byte cdde(s). The specific implementation of byte code 
interpreter 308, therefore, depends on the byte code set executable by the 
interpreter. For example, byte code interpreter 308 may implement a number of 
specific features in order to accommodate the type of code which activators contain, 
including any of the following: 

• Bitwise Operators Shift, rotate, and "extract bits" functions which are useful 
for cryptographic and marshalling routines; 

• Eval - explicit "call into data" that lets the bytecode interpreter interpret 
downloaded or modified bytecodes, thereby avoiding separation of code and 
data and con"espdnding flags and data protection; or 

• Interfacing Primitives - The SCDP client bytecode interpreter calls functions 
in other VxD's directly, including argument marshalling and intenializing a 
particular predefined set of C types. Both the SCDP client and CAS utilize 
Secure Stream Interfacing primitives, e g.. hobks to extract connection data, 
in particular authentication daita, frorii the streahfi to which the activator or 
technique is attached. 

It Will be obvious to those skille^^ 
also be impiemiented as a physical machirie. In t^^^^ simplest activator 
irhplementation described herein, bytecodes Accordingly, byte cckle 

interpretpr 308 may optional as well. 

Communication library 31:2 is utiliz^^ 
ARf^SD VxD nriodule 218 and the RAFT VxD mddule 222, Such library is similar to 
corrimunication library 304 of Fig. 30 and facilitatiBS communications between VxDs 
218 and 220. 
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Control module 310 Includes the necessary program logic or code to carry out 



the algorithm necessary to perform the installation abstraction, execute a title and 
refresh a RAFT token. More specifically, the algorithms executed by control module 
310 are Illustrated in greater detail in Figs. 4A-6 and their accompanying 
5 explanations. 

Fig. 3D illustrates cbnceptually a block diagram of the components comprising 
the RAFT VxD 222 of SCDP client 216. Specifically, VxD 222 comprises a RAFT 
RFC library 316. caching logic 318 and a control module 320. The RPC library 316 
contains the appropriate code and/or objects which implement the client side RPC 

10 layer of the RAFT protocol, described in greater detail herein. Such program logic is 
utilized to communicate with the RAFT server 206 utilizing one of the RAFT protocol 
messages. Specifically, module 316 contains the logic necessary to append a RAFT 
packet header, as described with reference to Fig. 1 1 , to each RAFT protocol 
message and to respond with the appropriate of the RAFT prbtoc»l messages. 

15 Caching logic 318 contains the appropriate code to perform caching of briqs, or 
portions thereof, retrieved from the RAFT server 206 using the RAFT protdcdi. the 
portions of the briqs cached by module 218 ifhay be stored in a portion of temporary 
memory on the host PC oh which the SCDP client 216 is exediitihg. The particular 
caching technique and its associated logic may be implemented in accordance with 

20 any number of a plurality of known caching algorithms, readily within the 

understanding of those reasonably skilled iri the arts. Contrbl module 320 may be 
implemented to include the necessary, program logic, code and/or objects to oversee 
. the previously described furictibns wirt^ 

; >i<iecute thte nfietho^ 



The flowchart of Figs. 5A-C illustrates the prbcedufal steps perforrtied by the 
SCDP client 216 during a typical title execution in accordance with this present 
Invention. As stated previpuisly, when a launch string is received by the iSCDP 
client's browser 224, the I^uiti()urp6se ihtisrnet Mail Extension (MIME) type 
associated with the iauhch string is located iri a rieglistty entry, which results in the 
invocation of the Lauricher moduli 220 within the SCDP client 21 6. Upon 
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invocation, Launcher 220 extracts the Universal Resource Name (URN) fnim the 
Launch String and requests the CAS 210 to perform a URN to URL conversion, as 
illustrated by step 6. the URN of the present inViehtiori is a unique identifier of a title 
within a briq. The standard URN fbitnat is as follows: 

urn:arepa://vendor/path/titlename[#^^ 

In the URN, the path to the title need not con-esponid exactly to the current 
location of the title In the vendor's storage server, the path is a categorization 
convenience, and is not necessary. The title's version number is optional, and may 
be sepiarated frdni the title name by a pound sigh. The vendor name may be 
registered with a central authority in order to ensure uniqueness. 

The Universal Resource Locator (URL) identifies the cunrerit location of a briq 
in a RAFT storage sen/er. The standard URL format is as follows: 

: raft://hbstname/path/briq^^ 

In a URL, the patti rniist con^espond exactly to the cun^ent location of the briq 
in the RAFT storage server: 

Figures 5A-C collectively fdrni a flow chart illustrating the process steps 
perfomled by the SCDP client and the modules contained therein during the 
subscription and title execution procesb in accordance with the present invention. 
Refemng also to the elements of Fig. 2B, a user of the host computer on which the 
SCDP client runs utilizes a web broWser 224 to select the desired title from virtual 
store front 21 5. The store front 21 5 returns a digital offer to the web browser, with 
the^ digital offer the user negotiates a purch^ 202 the 

eCommerce server transmits an unsigned launch 6^^^ back to the web browser 
over the network. The launch string is wrapped with a MIME header. When the 
launch string is received by the browser, the MIME type associated with the launch 
string is located in a file system registry entry feiultirig in the hvdcatidh of lauilchei^ 
module 220 of the SCDP client, aillliistfateid by step 502. Latihcher mcklule 220 
extracts the URN value frbm the lauhch string and transmits the URN value to the 
CAS server 21 0, a3 illustrated in pfbcedural step 504. Communications between the 
launcher 220 and the CAS 210 are established throijgh a sedtre RPC connection. 
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The CAS 210 provides a URN to URL donversioh and transmits the corresponding 
URL to the SCDP client Once the URL Is recelvedi as Indicated by decisional step 
506. the launcher 220 passes a request to reaid the URL header to ARFSD VxD 218, 
which. In turn, passes the request to the RAFT VxD 222. VxD 222 transmits the 
request using the RAFT protocol to RAFT server 206. The RAFT server 206 opens 
the URL and reads the header infontiation. The header information is then passed 
back to the ftAFT VxD 222, onto the ARFS VxD 2i8 and onto launcher 220. This 
whole process Is represented by prqceduirjal step 508 of Figure 5A. Next, launcher 
module 220 utilizes the header content to perform application testing requirements of 
the host system, as illustrated by procedural step 510. 

Following completion of the system testing requirements, the launcher module 
220 transmits a request for purchase authoriziation, via a secure RFC connection, to 
CAS 210, as illustrated in procedural step 512. In response to the request for 
purchase authorization. CAS 210 generates an activator, including a RAFT token, 
which is transmitted through the secure RPG connection to the SCDP client 216. 
Upon receipt of the activator, as indicated by decisional step 51 4. launcher module 
220 installs the RAFT token ahd activator, as indicated by procedural step 516. The 
activator is Installed In the ARFSD VxD 218, which. In turn, loads the RAFT token 
into the RAFT VxD. as illustrated by procedural steps 516 and 518. respectively. 
The RAFt VxD 2^ then transmits the RAFT token to the RAFT server 206 using 
brie of thei appropriate commands from the fV\frr protocol, as Illustrated by 
procedural step 520. Next, the ARI^SD VxD 21 8. through communications with VxD 
222 reads the ^iuper block field from the biiq located on RAFT server 206, as 
lliustrated by prbe^dui^ verifies a rtiagle nunlber in the superblocki as 

iliustratedbyproc^ . 
iririptertiented ais a cbhfetant sequence of bhMidle for example "ARFS." 

At that point, launcher nripdule^ti beigln^ to run the title executable file, as 
iliustr&ted by prodedural step 526. Ih tHe illustrative embodiment, the title executable 
is jn the fbmi of a WIndowis ex^cUteibie file; Ideated In the file sysiteiri implertiented by 
ARFisb VxD 21 8 using the data retrieved via F^FT VxD 222. 

RM=T VxD 222 begins to retrieve the. title directory and files from RAFT server 
206, asi illustrated by procedural step 528. The datablbcks comprising the directories 
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and files Of a mie are retrieved from RAR" server 206 using the RAFT proton 
the oommands described herein. Specifically, the VxD 222 retrieves the data blocks 
from the RAFT sierver 206 In a read-ahead ttrahnfef ^hd caches the datablocks to 
facilitate efficient decryption and exedution. 
5 t^'^ARFSD VxD 218 utilizes the activator, particularly the decf^^^ 

data, received from the CAS 210 to decrypt the data blocks retrieved from the RAFT 
server 206 and to perform integrity checking, as illustrated In procedural step 530. 
As described previously, the activator contains cryptographic Information which Is 
useful in decrypting the data contained within the briq prior to execution thereof. The 
10 Af^FSD VxD 21 8 maintains an iristallat|6n abstraction for the operating system 
creating the illusion that the file system necessary to execute the title is installed on 
the local host PC. as illustrated by procedurial step 532. The process by which the 
VxD 21.8 maintains the Installation abstractions described In greater detail with 
reference to Fig. 6. 

is The RAFT token received from the CAS 21 0 includes an end time field as 

described with reference to Figure 8 and its accompanying description. Prior to 
expiration of the activator and RAFT token, the launcher module 220 issues a 
request via a secure RPC connection to CAS server 206 for a refreshed 
activator/RAFT token pair, as illustrated by decisional step 534 and process step 

20 536. The new activator/RAFT token pair are installed and utilized in a manner 
similar to that previously described, as illustrated by process step 538. 

Installation Abstraction 

In accottlance with the present ihveritibh, the ti 
• 25 the SCDP client h6st system. The SCDI^ client softwsire CPfeates an installation 
abstra(^on, maintaining the illusiori for the local ^d^^^^ 

cun-ently executing is installed on the host computer. Thus, when execution of the 
title is terminated, there is no remaining evidence the title ran on the host client 
system. No files associated with the title are left on the host system hard-drive, and 
30 ho operating system state Information e.g., registry variables associated with the 
title, remain. The SCDP client system state after the title exits or the system crashes 
'Sthies^nie as beforie, except, possibly, for dpera^^^ 
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applications, persistent state, and changes made by the user of the application e.g., 
saviBd documents^ordata. The installation abstraction is achieved with a method of 
loading the expiected application state, before running the application, in such a way 
that the state can be unloaded when the application exits without affecting persistent 
5 parameteris. 

Each briq in accordance with the present invention, and as described with 
reference to Fig. 12, includes a file system for one or more specific titles. As 
described hereafter, a briq author utilizes a creator utility program to extract selected 
files from an application and the application installation directory. The briq author 

10 also extracts other information such as registry entries which may be necessary for 
the conrect execution of the application. The creator program combines the selected 
files and other information and generates as an output a file system in the fonti of a 
briq, as well as a set of database entries. The briq is stored on the RAFT server. 
The database entries are stored on the CAS server and comprise such information 

15 as keying infontiation and header check sunri values. 

Figures 6 is a flow chart illustratiriig the process steps perfonned by the SCDP 
client 216 and the modules 218-220 cohtairied therein to maintain the Installatibn 
abstraction during title execution In accordance with the preseht invention. Following 
selection arid negotiation for the purchase of a particular title, the launcher 220 and 

20 ARFSb VxD 218 mount the file system, as indicateid by step 6dd. arid store the 
associated registry entries on the local drive of the host system, as indldatdd by step 
602. A facility within the File Manager of Windows 95 , Windows 98 arid Windows 
NT bpersiting sys^^^ 
systerh, allows the file dirfed^^ 

25 "mbunted" or accessed over a dompute^^ neitWbric, thereby creaiting a "virtual driv^" 
from which data can be acceissed- in the present invention, mounting of the file 
system comprises using the previously described technique to access the RAFT 
server thrbu^h the SCDP client operating system interface. Mounting of the fije 
syisterii may result in cachirig all or a pbrtion of thie data blocks from a briq which 

30 cohtiain the titte content as well as the riggistry entries associated with the title. The 
series of registry gntries are stored locally on the SCDP client's host system memory 
and may include such infprniation as the directory where the title files have been 
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installed, etc. ARFSD VxD 218 further extracts the appropriate database entries 
from the CAS database 212. 

Using the keying information froni the activator, which has been foiw^ 
the SCDP client by the CAS sender, the data blocks from the briq are decrypted and 
5 executed as an operating system file system, as indicated by step 604. Data blocte 
from the briq are cached locally on the SCDP client on an as-needed basis 
throughout title iexecutton. During isxecutidn of the program, operating system 
device drivers, such as those contained within the virtual memory manager portion of 
the operating system make requests for registry entries stored on the local physical 

10 drive. Upoh execution of the application, the ARFSD VxD 218 starts intercepting 
such operating requests, as indicated by decisional block 606. The calls, where 
applicable, are satisfied with entries from the list of registry entries stored locally, as 
indicated by step 608. Some infomiation, however, is written directly to the operating 
system using the write-through techniques described hereafter. 

15 Interception of operating system calls, and satisfaction of these requests 

using the locally stored registry entries, continues until termination of application 
execution, as indicated by decisional step 610. At that point, the launcher directs the 
ARFSD VxD 218 to unmount or disconnect the file system, as indicated by step 612. 
As a result operating system requests are no longer redirected to the locally stored 

20 registry entries. Both the locally stored registry entries and any data blocks which 
have been cached locally may be either erased or over written. As a result, the state 
of the SCDP client prior to execution of the title or application is returned to Its status 
quo without any remnants of installation of the title, except any limited write-through 
data which the uSer intentionally wis 

Write-4hrbugh locdl storage 

During the generation of a briq by the author utilizing the creator program, 
files and directories can be tagged with a"write-through" attribute. Briqs containing 
write-through files or directories may contain a container with the tag, LOCL. This 
30 container contains the full path of all write-through directories and the path of any 
directory, other than the root directory, which contains write-through files, ^s^ 
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with the tag LDIR; The user is allowed to specify that the pathname of the root 
directory for locally stored files, the new pathname contains the Vendor field from 
the URN in order to ensure uniqueness. This infonnation is stored in the ROOT tag 
in the title's LOCL container. By default, ARFSD VxD reports 0 bytes free on the 
5 local drive. Briqs containing no write-through files or directories will always report 0 
bytes free. The presence of the a tag in a title's LOCL containeif^ specifies that 
ARFSD VxD should report the amount of free space on the drive containing the local 
stofage directory. Titles need a LOCL container only if they need to specify non- 
default values for the ROOT. 
10 When a briq containing write-through files or directories, i.e. containing a 

LOCL container in the header, is loaded, the launcher within the SCDP client creates 
a directory for local storage under the SCDP install directory. This directory is 
derived from the URN unless a directory is specified by the ROOT tag in the title's 
LOCL container. The launcher creates a sub-directory in the jocal storage directory 
15 for each directory specified with the LDIR tag in the header. The root pathname of 
the local storage path is passed as well as whether to report free disk space to 
ARFSD VxD when loading the briq. All files in local storage areas are deleted when 
the Launcher software is uninstalled, and. optionally, upon title exit These locally 
stored files are persistent by default. Launcher must create directories in local 
20 storage for all write-through directories in a briq. 

When a write-through file is started, the information is taken frorin the file in the local 
storage area having the same naming convention ias directories mentioned above. If 
thi? file ddesht exist in local storage, it is firet copied there from the briq. The original 
iRIe in th^ briq rriaiy not bb conipres^iSd or ehbryp 
25 eribryptidn. Wheri a write-through ^fi^^ is oj^ened, the copy on local disk is opened, 
and all requests on the AR^^^ 

Cbriditional Acress Seirvef (CAS) 
Figure 7A is^aconbeptual block dia^ 

3d (CAS) 700 and associated database 750. In the illustrative embodiment, the CAS 

may be implemented as an application execuisible on a P0SIX.1 (IEEE Std 1003.1. 

1 998) compatible platform, such as the Suh i^olaris® operating system commercially 
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available frorn Sun Microsystems, Palo Altb, CA; or the Linux operating system 
commercially available from Red Hat Software, such platfpmis may execute on a 
computer architecture similar to that illustrated in Fig.1 . The CAS application 702 
further comprises a database interface module 704, a remote procedure rail 
5 interface 706. a URN to URL conversion module 708, an activator factory 71 0, and a 
URL verifiraflbn module 712. 

the database inferfece module 70*4; intfeifaces with the GAS database 750 
and may be implemented using coifimeircial database products. Database 750 rnay 
be used to store short-tenn stay data, such as the stay data of a token requesting 

10 li^fresh, or long-tenm stay data, such as titie names, crytographic key information, 
and other infonnation for titles available over the SCDP system. Database 750 may 
be shared by multiple CAS servers 700, if more than one CAS server is present in an 
implementation over a network. Database interface 704 and database 750 
communicate the SQL standard database query language. The SQL standard is 

15 published by the American National Standards Institute (ANSI). Database interface 
704 comprises a set of objects that filter quenes received by the server 700. Such 
filters are useful in focusing or customizing the scope of a database query. 

CAS server 700 is coupled to the rest SCDP system via network 205, which in 
the illustrative embodiment is an Intemet protocol based network implemented in 

20 either the fonn of a local area network or a global network. Server 700 interfaces 
with network 205 through a remote procedure called module 706. Module 706 may 
comprise code or objects which adhere to the open network computing remote 
procedure call standard, published by Sun Microsystems (RFC 1057 issued by the 
Intemet Engineering task force). Such RPC standard defines code which cor)trt)ls 

25 the flow ^nd function calls between two entities trying td communicate iBmotejy over 
a network. Module 706 may be implemehted with any number of commercial tools 
available which make remipte procedure Callis iappear similar to subroutine function 
calls, Once such product useful for implementation of module 706 is the Noblenet 
Secure RPC from Nobleniet. Inc., Southborough. Massachusetts. The Noblenet 

30 Secure RPC provides i standard RPC interface with an additional security layer. 

URN to URL conversion module 708 comprises code or series of objects 
which, if given a URN query database 750 and return a con-espondlng URL. Such 
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URNs are received from the launcher module of the SCDP client over network 205. 
Database 750 where the URLs are stored may. be implemented as a sequential 
database hjaviri£j a plurality of records. Module 708 fonvards the appropriate query 
to the database interface 704 and receives the appropriate URL from the database. 
5 Module 708 then transmits through RPC module 706. the con^esponding URL to the 
SCDP client over the Network. Alternativejy. in an environment where a limited 
number of titles and/or content servers are utilized, the URLs may be stored on a 
disc associated with the server and module 708 may comprise program logic to carry 
out a look-up table conversion of a received URN. 

10 The conversion module 708 converts the abstract URN data structures to 

specific URL data structures and may be implemented with a series of conversion 
tables and associated comparison logic. The URL verification module 712 
comprises code or equivalent objects which receives a launch string from the 
eCommerce server 202, as explained in greater detail hereinafter, time stamps the 

15 launch string and digitally signs the launch string through use of a hash code and 
encryption key. Specifically, a message authentication code may be appended to 
the launch string as received by the CAS 700. The message authentication code 
may include a hash code generated in accordance with the MD5 hash algorithm and 
further includes an encryption key which may be generated in accordance with any 

20 number of encryption standards including the Data Encryption Standard (DES). The 
digitally signed launch string is then fonwairded to the eCommerce server 2d2 for 
transmission back to the client host systerris web browser as described herein. 

In the SCDP system, the activator serves as a mechanism to del^^^ 
information to pptentid^^ 

25 Module 710 of serv^^^ 

series of byte codes and appends a crytographic key to the series of byte codes, the 
key being retrieved, in one implementation from database 750, The implementation 
of the activator generation module depends in part on the sophistication of the 
activators utilized within the SCDP systiem! Folr ah activator comprising a series of 

30 byte codes and a key appended thiereto or integrated therein, the activator 
generation module 710 has the iniplementation described above. In alternative 
embodiments, where the key is intie^rated into the activator in a more secure 
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manner. e.g., folding the key Into the byte cod6 sequence, additional logic and/or 
objects would be required to implement such functions within module 710. For 
example, rather than appending a l<ey to a series of byte codes, a sequence of byte 

codes which perfomi a function, such as geriei^ition of a number or performing othe^ 
5 logic operations may be inserted into the activator; In such an emiiodiment, the 
module 710 may include logic to randomly select from one of a number of byte code 
siequence or techniques described herigin as code obfuscation techniques. With 
such an embodinrjent, the module 710 is capable of randomly generating activators 
with a higher degree of security. Alternatively, with more sophisticated activator 
10 impletih6ntations, iictivator module 710 may geiierate an act 

activator generation routine which may be resident in an extemal library. 

The above-described GAS modules may perform five primary functions within 
the SCDP system. First, the CAS provides users with the cryptographic activators 
that allow one-time use of encrypted briq content. Second, the CAS insures that the 
15 SCDP system can accurately track the usage of titles and to support a security 
model in which development of a "hacked" die^^ 

difficult. Third, the CAS provides limited-lifetime! f^FT authorization tokens signed 
with a CAS private key and bundled with ah attivator. The RAFT client includes tiie 
authorization token with it's RAFT requests. The RAFT server uses the token to 

20 verify a client's right to access the requested content Fourth, tiie CAS interacts with 
the eCommerce software billing system to "settie" transactions. The ti^nsactloh 
setflement is not done during purchase negotiation but is delayed until the CAiS is 
assured that the end user has beisn able to mn the content successfully. Completion 
of the first adivator refresh is art indicatibri tiik the 'title is rtinrilhg succesbftilly. ; ; 

25 F^ifih, the CAS maintains a database for We usage repbriihg &hd activator tracking 
Three types Of logs may be assoclatiEkJ w^^^ 
logged to a stendafrd UNIX texl log. This log is i^^^ 
Second, tiie CAS records transactions Into the CAS d£^^ 
purposeis and for activator tracking: These re(k)rxls arB in^a^^^ 

30. the e-wmmerce systemi which are used for a^^ 

database itself keeps InteiTial transaction logs. Which are ttie mechanisms used to 
insure that database transactions ^re cbmpletaJ ornjiled back successfully. Such 
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functionality may be Internal to the CAS database. In the illustrative embodiment, 
the CAS will use a commercially available database maintenance software such as 
that commercially available from Oracle Software to insure that a purchase is 
committed or rolled back. Database transactions are diffeirent than financial 
transactions described above. A financial transaction may be a database 
transaction, but many other transiactiohs such as updating a user name, may be 
databasie transactions. 

In the illustrative embodiment, the CAS supports an administration interface 
with which an system administator can monitor CAS status, for example, the current 
nuniber of database connection threads In use and the current number of user 
connections, i. e., connection threads in use. In addition, statistical information such 
as the peak number of user and database connections used since startup: the 
number of times since startup that user or database connections have reached a 
predetemiined limit may be made available. 

The SCDP client interacts with the CAS by means of a client library. The 
client library may be specific to each client platfonn, because it uses platfdrm-native 
methods to communicate with the SCDP client GUI. In the illustrative embodiment, 
i.e., the Win32 platfomn, the client library is called CASLIB32. The client library 
exports the CAS interface classes CCAS, which represents the transport to the CAS, 
and CCasSession, which represents a specific client session. An Application 
Program Interface (API) allows the CASLIB32 client to negotiate for muttiple titles 
simultaneously by^ using multiple sesstons. the API also exports extra classes that 
repr(Bsent infonhation passed to and received from the CAS that insulate th6 CAS 
ihterfaeefrdiTi the specffi^^^ 
impleriieriteid as; ^Activator. CUri;ete. th^^^ 
client t)y sending Windows messages: 

CAS support for Activators 

The simplest implementation of ari activator is a bytecode nsutine that has the 
key for a given briq compiled into the activator. With this activator implementation, 
the CAS authenticates the client, idehtifies the purchased briq. constructs the 
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activator bytecode and downloads th6 activater, The SCDP dieht can then ctose the 
connection and mn the title. Such activators may be generated in advance and 
retrieved directly from a database by tlie GAS activator factory 71 0 and interface 
704. 

5 In a more sophisticated activator implementation, the activator is aware of a 

cryptographic algorithm, and requests a key from the CAS. The CAS has 
authentication infonnatlon and security data from the existing stream, and can have 
a pi-edefined RPC response for "request l^ey*" with whatever arguments are needed. 
In anotiier implementation, ttie activator may have ari}itrary code for some 

10 new mechanism, possibly requiring multiple stages. The activator can make a 
Remote Procedure Call to tiie CAS with opaque arguments and a specification of a 
"technique," as explained hereafter. The CAS thien dispatches the opaque data to 
the Technique^ which returns opaque data to tile client or makes otiier calls, or calls 
out to other servtees. Ifthe CAS has its own interpreter, tiie CAS can retrieve the 

15 code for the Activator and the tedinique from the database. If all Activators are pre- 
generated, tiiere may be many possible activators for any single technique. 
Alternatively a database of obfuscations and a siBt of rules for how to combine them 
may be mialntained by the CAS. 

The CAS selects an activator appropriate to a given client, product, and 

20 purchase. The CAS delivers the activator, and "supports" the activator through 
additional RPCs. Many CAS RPCs can be predefined, such as a simple "request 
key" for a given briq. Such RPCs may be restricted based on the particular activator 
selected. For example, most clients Won't be permitted the sirtiple "request key" call; 
but would be required to peiforiti whatever calls tiie Technique expects the activator 

25 -touse. 

Refemng to Fig. 7B, a flowchart illustrating the process steps performed by 
tiie CAS 700 during the subscription arid title executbn process is lllustes^^ 
Specifically, CAS 700 receives a launch stiing, as describied with referenced to Fig. 9 
and its accompanying explanation, frdrh the^Cbmirierce server, as illustifated iri ^tep 
30 720. Next, the CAS digitally "signs" tile launch string, as indicated in procedural step 
722. The CAS "signs" tiie launch string with ia private cryptographic key. The signed 
launch string is ttien fonvarded from CAS 700 to tiie SCDP client executing on a host 
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system connected to thie broadband network, as illustrated by process step 724. 
The SCDP client extracts URN from the launch string, as described herein with 
reference to Figs. 5A-C and their accompanying descriptions, and transmits the URN 
to CAS 700, CAS 700 receives the URN from the SCDP client, as illustrated by step 
726, and perfoftns a conversion of the URN to a URL, as illustrated by procedural 
step 728. As described previously, the CAS 700 perfonns the URN to URL 
conversion using module 708 as described previously. Such conversion may include 
a query of database 750 or use of a table look-up algorithm, depending on the 
implementation of module 708. The CAS 700 transmits the URL list to the SCDP 
client, also illustrated by procedural step 728. Next. CAS 700 receives a purchase 
authorization request from the SCDP client, as illustrated by procedural step 730. 
The purchase authorization request from the SCDP client includes the launch string. 
CAS 700 then verifies the launch string to determine if the launch string had been 
previously signed by it. or, in an implementation with multiple conditional access 
servers, by another authorized CAS server, as illustrated by procedural step 732. 
GAS 700 then generates an activator for the clierit requesting purchase 
authorization, as illustrated by process step 734. Activator generation occurs In 
accordance with the specific implementation of module 71 0 of the GAS server, as 
described herein. 

Next. CAS 700 transmits the activator as well as a RAFT token to the SCDP 
client, as illustrated in procedural step 736. The CAS 700 retrieves the RAFT token 
from database 750. The RAFT token has the format illustrated In Fig. 8 and as 
described in the relevant portions herein. The activator and RAFT token enable the 
SCDP dieht fo access the desired t^^^^ title data as 

(iescribed hfeirein. At this i)o|nt. t^^^^^ regartiing ih^ 

specific SCDP client until an a^ivator token refresh request Is received from the 
SCDP client, as illustfated by decisional step 73^. Upon receipt of the first refresh 
rKjuest from the SCDP client, the CAS 700 posts the tt^^ 
eComhfi^rce server', as lllus^ted by procedural step 740. Posting of the transaction 
with the eCommerce server comprises ttie actual recorded acknowledgement that 
the user has paid for the identified title. Such posting is delayed until the first refresh 
request to ensure that the title Is executing properiy on the SCDP client, the time- 
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out mechanism within the activator initially sent from the CAS to the SCDP client 
expires after a predetenrilned inten^al, Iridlcatlng thait the title is executing 
appropriately. The CAS issues a hew token, as Illustrated in procedural step 742, 
and transmits the pair to the requesting SCDP activator client. The RAFT token life 
5 time, as Indicated by the start «me and stop time fields of the RAFT token, may Be 
tonger than the lifetime of the token initially transmitted to the SCDP client with the 
activator. Subsequent requests for activator/token refresh from the SCDP client will 
not cause the CAS to post the purchase of the titie to the eCommerce server. As 
described previously, all communication between the SCDP client and the CAS 

10 occur oyier a seoire RPG cbnnectioh, such connection may be established using a 
commercial product which adheres to the RPC standard . 

As may be appreciated by those skilled in the art, the process outlined in Fig. 
7D highlights those steps executed by the CAS in relationship to a particular SCDP 
dieht Which will terminate when title execution ends. It will be obvious to those 

15 reasonably skilled in the art that the CAS may be implemented as a multi-tasking 
application In which several separate threads are currently executing various steps 
of the illustrated process. Accordingly, while servicing the requests of a specific 
SCDP client, the CAS may be concun-ently servicing the requests from other SCDP 
clients as well. 

20 

i^PC transpbrt 

The CAS and CASLIB32 communicate through a standards-based Remote 
Procedure Call library, suchas the NobleNet Secure RPC. The SCDP dlent msikes 
synchronous calls to the CAS, which assigns them to a thread for processing. 

25 CASLIB32 presents an asynchronous ihtefface to its attached GUI, so internally it 
queues the syrichrorwus RPC requests and places them from a background thread. 
To provide high transaction throughput, the CAS maintains a pool of ready threads 
tfiat can be used to ran tasks. The thread pool is a reusable C++ class. Inccwnlrig 
taisks are intercepted in the RPC layer, queued to the tiiread pool, and eventually 

30 processed on a thread as opfposed to being processed inline. The thread pool 
allows the CAS to process higher simultaneous hfartsactfon rates and perform better 
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under short load spikes. The RPC calls need to allocate thread-safe memory that 
can be tagged and freed later, because buffers ciahriot be freed until the RPC 
transport is done sending them. The CAS uses a reusable C++ memory pool class 
that can delete memory by thread id. 
5 The CAS nrfay be implemented as a stateless server, like a web server. A 

stateless server has thie advantage that it can be easily scaled by deploying more 
server machines; and using "round robin" software to parcel out incorriing 
connections to the servers, since an SCDP clienfs subsequent requests do not need 
to go to the server it originally connected to. The CAS maintains a connected socket 

10 TCP stream between requests, so some infomiation could be attached, such as a 
transport session key. If this connection is dropped, the CASLIB32 will attempt to 
reconnect, potentially to a different CAS process, so pushing state out to CASLIB32 
or into the database is preferable. 

To facilitate high transaction volume, the CAS is designed to make use of a ' 

is pool of multiple active database connections. Server thrieads request connections 
from the pool, which reconnects dead corinectiohs in the background as necessary 
to minimize database connection latency. The database connection pool js 
implemented as a reusable C++ dass. the CAS usies an abstract database 
interface called D^Object, which is implemented as a reusable .C++ daiss and allows 

20 the CAS to be ported easily to other databases. . . 

Raft token 

: To impfpve the overall sediH^^^^ 
the SbCP client with a signed RAf^ Authorization the FiAFf token : • ^ • ; ? 

25 authbnzes a particular SCDP client to a^^ 

period. The CAS digitally signs the RAf^ Token, using standardized, public-key 
digital signature algorithms. In order to access a executable content on a RAFT 
server, the RAFT VxD must present its token to that server. The RAFT server : 
verifies the CAS's digital signature and then Veiifies the token's cbhtehts. The RAFT 

30 token 800 is valid for any number of the RAFT servers Within a CAS's admiriistirative 
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domain; i.e., a broadband service provider may instail multipie RAFT servers on their 
network, and the RAFT toiten woul(f be adrhissible by any of them. 

in the illusftrative embodiment, the RAFT tol<en is implemented as a data 
structure having the fortfiat iliustrated in Fig. 8. The RAFT tol<en 800 comprises an 
5 URN. an ORN length 804, a start time 806i an end timfe 808. an IP address 810, and 
a CAS signature 81 2. The URN 802 arid its associated length 804, define the 
specific title that the RAFT token witt unlock! The start time 806 and end time 808 
define the lifetime of the token. The fonnat of the described URN has been 
described previously. The RAFT authorization token contains the RAFT client's IP 

10 address as a 32-bit value in network byte order, the requested URN, and 32-bit start 
and expiration times. The times are defined as POSIX 1 003.1 -1 988 "seconds since 
the Epoch" or approximately seconds since 00:00:00 GMT, January 1. 1970. The 
CAS signs the token with the GAS group's private key so that the F^FT server can 
validate its authenticity. The RAFT server will deny access if server's cun-ent time is 

15 not within the token's window. The IP address defines the networi^ address of the 
SCDP client requesting the activator/token, the RAFT server will deny access if the 
SCDP client providing the token does not have the same IP address, thereby 
preventing another client from using a stolen token. 

The RAFT token is transfen-ed to the client as part of the activator. RAFT 

20 tokens are refreshed alohg with activators; The activator is constnicted w/ith a time- 
to-live mechanism. The SCDP client issues a CAS request, via the RPC 
mechanism, to refresh the at^vatoi/fokeh combination prior to expiration of the 
existing activator. 

;25 Random Access FUe Transport Protdcol and S^rire^ 

Figure 1 0 illustrates conceptually a block diagram of tii^ RAFt Seri/er 1000 
and its accompanying database 1 050. In the Illustrative embodiment, the RAFT 
Sen/er 1000 may be implemented as an applicatidh executable on a P0SIX.1 (IEEE 
Std 1003.1, 1d98) compatible plsrtfbrm. subh ^s the Suh Solaris® operating system 

30 comrtiercially available from Suh Micndsysteriis. P'alo Alto, CA, or the Linux operating 
system commercially aviailable fibm R&d Hat S6ftw^re, such platfomis may exiecute 
oh a computer architecture similar to th£it illustrated in Fig.1 . 
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The RAFT server may be implemented as a RAFT application 1002 and a 
Simple Network Management Protocol (SNMP) master agent 1004 executing on top 
of the operating system. A commercial product suitable for implementing the SNMP 
master agent 1004 is the Emanate product commercially available from SNMP 
5 Research, Inc. The master agent 1004 communicates with network 205 using 
published appiication program interfaces in accordance with the SNMP standards. 

The RAFT application 1002 comprises a POSIX (Portable Operating System 
Interface Standard) file input/output module 1006, a file system interface 1008, and 
SNMP instrumentation module 1010 (i.e.. the RAFT SNMP sub-agent) and a 
10 network/RPC/RAFT protocol interface module 1012. 

The SNMP instmmehtatioh module 1010 contains objects or con-esponding 
code which collects statistical and logistical information useful for a system 
administrator in throttling the bandwidth of the network to improve network 
perfonrnance. As such, module 1010 is ah optional element of Raft Server 1000. 
15 The RFC Raft Protocol module 1 01 2 interfaces with the IP based network 205 

using a proprietary RPC protocol as defined herein. Module 1012 includeis the 
necessary code and/or objects to irhplertient the protocol and to verify the conterits 
of the RAFT token. 

The file Input output module 1 006 may be ah object-oriented implementation 
20 Sccbrding to POSIX standard 1003.1 published by the Institute of Electrical and 
Ele(itr6riic Enginieets (IEEE). The POSIX I/O module 1006 provides a local file 
systehri interface abstraction for memory discs ibso. Memory 1050. illustrated 

V Gohcei)^^^^ 

I : : 6mij0dihtent; 1^^ heeider poirtioh bfa which isftinericoded aridthe 

; 25 ;body ppilipri are stored toigether* Hdwever, they ar^ 

acdesi^ea inde^^^^^ File 
systenri interface module 1 008 contains program logic which receives requeists for a 
particular briq and /fhaps the briq Into the directory and file where it is stored in 
^: ; In this manner, file syst^m^ interface 1008 functions as an interface 

30 betvveeh the network request frbrh the SCDP system arid the rtiemory 1 050. In the 
illustrative embodiment, riiemory 1050 may be implemented as one or rnore discs, 
e.g., a RAlip disc array or a disc fanti. The file system interface module 1008 
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Interfaces with the file input/output module 1006 gnd the ne^^ 

1012 and implements program logic for ao^ssiiig files a^^ 
herein. 

The SNMP master agent 1 004 provides SNMP protocol services on behalf of 
5 the RAFT SNMP subagent. which is embe«ided within the RAFT application. The 
RAFT application uses its SNMP subagerit to make Its management accessible to a 
femote SNMP manager 

The following steps describe the interaction between the SCDP client and the 
RAFt server, the Launcher launches a title. Launcher contacts the CAS server to 

10 obtain a list of URLs that con-espond to the requested URN. A URL identifies the 
location of a particular briq, including the RAFT server on which it resides. For each 
RAFT URL, a weight may be returned to help select the most appropriate URL. A 
URL is more desirable when it has a higher weight value. 

Following the URN-to URL conversion by the CAS, the SCDP client sends the 

15 CAS a purchase request described previously in the discussibn of the CAS 
exchanges. In response to the purchase request, the CAS server provides the 

SCDP client with an activator containing the RART Authorization Token for the 
selected URN. Note that the Authorization Token is valid for any of the URLs 
associated with the selected URN. 
20 Launcher tf^en examines the list of URLs to deterrnine if any RAFT URLs ar6 

present. If RAFT URLs ai-e present, the Launcher sends only the list of RAFt URLs 
along with the RAFT access token to ARFSD VxD which will fonward this infbnnation 

i e. the RAFT A^D Of tlie S(3j^ 
provides a weight fpr eadi of the RAFT URLs, these weights rtiay be different tfeh 
X . - ; by the CAS during-thi^ thg RAFTtJi^ht 

tiifen establishes a connection With one bf the^ 

URLs. The RAFt client miay contain the appropriate program logic whteh enables it 
to use tiie weights provided with tfie URLs to deqWe which RAFT server to contact 
\ . ^ /first. ■ 

^^^^^^ : ; 3^ ^hel^FT client then atterfipts to o^^^ jhe 

client spedfies a protocol versiori; the path riartie (from tiie URL) and the RAFT 
= access token. The protocol version Is a 32-bit value used to verify Uiat the fRAFT 
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Client and RART server are protocol compatible. To validate access, the RAFT 
server Verifies that ttie URisi provided In th^ tol<en is one of the ones listed in the Briq 
header. The RAFT seirvef :tOdO checks the RAFt token's start and expiration times 
during the op6n. If the RAFr_OPEN is successful, this RAFT server returns a RAFT 
file handle and ia uhlque ID forthe Briq, e g. a hash of the Briq tag, used for caching. 

In order for the RAFT server to Validate the expiration time, the RAFT server 
time is synchronized with the CAS to within a predetennined interval. The RAFT 
seo/er therefore accepts start times earlier than the current time and does not deny 
access until after expiration of the interval. The tol^en expiration time is proposed to 
be some multiple of the Activator keep-alive tihie plus additional time to handle 
varying network and server latencies. 

On each subsequent RAFT read request, the RAFT server checks that the 
access token has not expired. The RAFT server will fail any request that occurs 
when the server does not have a valid access token for that particular client. 

Eventually, the RAFT access token will expire. The SCDP client's activator 
keep-alive mechanism is responsible for obtaining a new RAFT token before the 
current token expires, this insUre^ RAFT token^ are refreshed in timely manner so 
that access failures will not occur under normal operating conditions. When the 
RAFT client sends the token to the RAFT sen/er during a RAFT_QPEN. fRAFT client 
must compute how long the token is v^lid from the start and expiration time. Since 
the RAFT client cannot yerify the legitimacy of the foken contents without the CAS* 
public key, RAFT client must wait for a successftjl RAFT_OPEN to determine that 
the token is valid before setting its nefresh timis. However, the refresh time is based 
U(M)n wheh RAFT clie^^^^^^^^ 

cbrntileted. to insurie uhiriterifuptfed aa;0s^ m RAFT client requeste 

a new fWT access token froin the CAS in advanoB of vvhen the token expires. 
Upon receipt of the new RAf=T access token, the RAFT client will send a 
RAFT_REFRESH operation with the hiewly obtained token to the RAFT server. 

When the RAFt client Is finished jiccesising a Briq, the RAFT client sends e 
RAFt_CLOSE message with tHie RAFT file haindle. If the RAFT server loses the 
connection to the RAFT tdient, all open files coiti&spondirig to that conniection are 
automatically closed. 
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Raft Packiet Header defihition 

All communications in accordance with the RAFT protocol contain a RAFT 
packet header 1 1 00, as illustrated in Fig. 11 . The RAFT packet header 1 1 00 may 
be implemented as a data structure comprising a procedure number data field 1 102, 
a sequence number data field 1 104. a packet length data field 1 106. and a status 
data field 1 1 08. The procedure number field 1 1 02 indicates the RAFT protocol 
message type and may be implemented in the form of an integer. The sequence 
number field 1 1 04 is used to match requests with responses and may be 
implemented in the form of an integer. The sequence number is only unique per 
connection. The packet length field 1106 indicates the size of the packet data, not 
including the size of the header, and may be implemented in the fomi of an Integer, 
the status field 1 108 Indicates the status from thfe RAFT request and may be 
implemented in the font) of an integer : A non-zero status indicates Uiat the request 
failed. Different protocol messagias will return different status codes. However, a 
status of zero indicates that the request cbrhpleted successfiilly. A non-zero status 
resuite in the length field being set to ziero, iridic^tlhg that no packet data will be 
returried if a request fails. In accordance with the RAFT pnatbcol the packet header 
is followed by the RAFT packet data. 

RAFH* Protocol Messages 

The RAFT protocol consists of four distinct protocol hiessages which enable 
briq access arid RAFT token riian^igement. Aft^^^^ TGP conhectiort, 

the initial RAFT protocol nrteis^age c^ one of Its 

arguriients in order to identify the protocol version of the^r^^^ 
description of the RAFT protocol messages as follows, the RAFT^OPEN function is 
called with a protocol version, a token length; a RAFT access token, a piath length, 
^rid a null-tennihated full path name. ;Upoh success, the result is a RAFT file handle, 
a RAFT ID, and the maximum read length supported by the RAFT server. The 
RAFT ID maybe U^ed to generate ah SCDP Client cache tag. Thie RAFT ID may be 
the Brkj ID to enable consistent caching ecross ririultiple RAFT servers in case^il- 

40 
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over occurs; The maximum riead length is intended to infonn the RAFT client about 
how much data it can request during a RAI=T^READ operation. 

The RAFT„REFRESH_TOKEN function enables the RAFT client to update 
the RAFT sen/er with a newer RAFT access tol<en and is called with a token length, 
5 a RAH" access token and a RAFT file handle. Upon success, the new RAFT access 
token replaces the cun-ent token associated with the specified handle, effectively 
increasing the expiration time of the token. The cunreht token will be retained if the 
new token is invalid. This function does not return any data, but the status in the 
header is updated to reflect success or failure. 

10 RAFT__READ function is called with the RAFT file handle returned from the 

RAFT^OPEN call, a 64-bit offset, and a length. The RAFT file handle must be 
associated with a valid access token in order to access the requested data. 

The RAFT_CLOSE function is used to close an open RAFT file handle. The 
call takes a RAFT file handle and does not return any data. Howevisr, the status in 

1 5 the header is updated to indicate success or failure: 



Launch Stririg 

Fig. 9 illustrates a launch string 900 in accordance with the present invention. 
The Launch String 900 may be implerrfented ais a data stnjcture comprising a URN 
20 data field 902, a Store ID date^fi^^^ 

domain data field 908 and an amount data field 910, as illustrated in Fig. 9, The 
Mnlquely identifying the desired content and mdy be implemented, as 

J deisicribe^ 

V systeril a^^ niay fae implemenfed jn the alphiEinuiiiieric chiaractef 

25 Stririig or an integer, St6r6 IDs are Used to sepai^ra^^^^ transactions frcim different 
storefronts for reporting purchase. Multiple storefronts may share a stor6 ID if they 
are really representing the samis organ The goods type 906 indicates 
whether th6 transabtioh should be i purchase thrdiigh a subscription or through a 
microtransaction and m^y be im^^^ in the fbrtn of a numeric or alphanumeric 

30 character string or iah integer. A substriptibn trarisadtion is a single payment for 
unlimited use of a title or set of titles over a specified period of time. A 
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microtransactlori is a diafge against a user debit account, and is used to support the 
"pay-per-single-use" payment model. The subscription domain 908 indicates if the 
transaction is covetred by a spedfic subscription offer for example, "Weekly Hot 
Game Pack" or "Small OiffiGe Applications P^icks^e." applica^^ 
5 l^e subsdriptfoh domain may be inipteftl^ 

alphanumeric character stririg or an iriteger. the amount field 910 indicates the 
puri*ase amount of the micrbtransaction and ma/ 
integer. ' ■ ■ • 

The conteaits of launch string 900 ate generated by the eCommerce server 
10 front end module 1408 as illustrated in Fig. 14. The CAS digitally signs the launch 
string 900, using, for example, a standardized, public-key digital signature algorithm. 
Thereafter, launch string 900 comprises an additional CAS signature field 9 1 2 which 
identifies the CAS group's private key. The Launch String Is sent to the SDCP client 
vrfa the eCommerce system, as part of the fulfillmerit process. The SDCP client 

15 passes the Launch String back to the CAS during its pre-launch negotiations with the 
CAS, las explained herein. 

eCbmmerce Systerii 

An electronic commerce software application, hereafter refen-ed to as 
20 eCommerce system, suitable for use With the present invention is Transact 4.0, 
commercially available from GpenMari<et, Cambridge, MA. eCommercis software is 

used for managing user accounts aind conducting financial transactions, including to 
1 ) maintain user account iiiforitia^^^ 

arid verify Crfedit card inforiifiatbh, and 4) s^^ 
7 " ; 25 Refenihg again to Fi^; 2, e^ 

a^)piiCatioh liiririm^ 
reference to Fig. 1 . the applkatiori ^ 
system such as Sun's Solaris pp^ratirig 
for executing sieh/er-tyj^ 

30 14 corriprises a hardware platfomi 1402 on whldi an operating system 1404 
executes. The actual eCdmmerce gerver application 1^^ 
module 1408 and a back end module 1410 to the various other components of the 
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SCDP system 200. Specifically, front end module 1408 of server 1400 may be 
implemented to produce a web servier front end to the other cornpohents of SCDP 
system 200 through network 205. Such a front end is similar to other web servers 
which cunrently exist on the Internet. The back end 410 module of server 1400 
interfaces with billing database 204 and Implements logic arid/or objects necessary 
forquery the database and executing trahisactions and microtransactions associated 
with the negotiation and purchase of a title. As mentioned previously, eCommerce 
server 1400 maybe coupled either through a private local area network or over a 
global ariea network, such as the Internet to a third party credit processing server of a 
bank or other financial Institution which may perform services such as credit card 
clearing, electronic account debiting, etc. Front end module 1404 and back end 
module 1410 of server 1400 communicate through a series of scripts written in 
accordance with the Common Gateway Interface (CGI) standard. It will be obvious 
to those reasonably skilled in the art that other commercially available electronic 
commerce server applications may be utilized with the inventive SCDP system in 
addition to those mentioned herein. 

Database 204, associated with server 202 may comprise a conventional serial 
data base and is used to store criedit and billing information necessary to carry oh 
transactions. 

Front end module 1408 of server 1400 further comprises the necessary code 
or objects to generate launch strings as explained in greater detail with reference to 
Fig. 9. Once gisnerated, the launch strings are forwarded to the CAS server for 
digital signing thereof. ; 

(n th6 iilUstrativre erhto^ feCbmnlerbe system cbrii^^ 

and the stor^frbht which w6ri< together the user to navigate through a 

catalog arid accegt arid validate purchase Infoniiation. The eCbmm6rce system 
uses an open web-based architectui^e for interfacing with external conipohents. th6 
irivfentive SCDP system software modules communicate with the eCommerce 
software by posting URLs to the eComnlerce software's web server front end. In 
responding to the poisting, transact rfiakes a call to a CGI program with ispecific 
arguments encoded In the URL Evaluating the URL via the CGI call causes the 
Transact software to change the database state. An entire transaction sequence is 
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completed by simply evaluating a set of URLs. The e-commerce system will 
captured and maintain client data, such as user accounts or credit card information. 

Assunring the eCommerce system is a full-featured system that provides the 
ability to conrwnerce-enable a storefront and conduct credit caid transactions through 
5 the web, Interaction between the CAS and eCommerce system occurs primarily in 
three different places. When the user has purthaisfed ai title, the user is presented 
with a page, referred to as a "Digital Receipt*, on which appeare a link called the 
Fulfillment URL. The Fulfillment URL is really si CGI program whose purpose is to 

obtain a Launch String from the CAS. As described in greater detail hereln, a 
10 Launch String is a collection of all the irifohnation needed for the CAS to later 
recognize the user's right to the software and then settle a transaction with the 
eCommerce system. This information is returned in a form that only the CAS can 
recognize, so that the CAS can later validate Its own Launch Strings. Returning the 
Launch String to the client browser triggers the browser to activate the Launcher 
15 within the SCDP client and pass the launcher the Launch String. Subsequently, the 
Launcher may provide a launch string to the CAS arid request an activator. The 
CAS verifies the Launch String and asks the eCbmiTierce server to validate that th 
pui-chase, if settled, would succeed. However, the CAS does not yet actually settle 
the transaction. At this point the CAS returns an activator to the Launcher and the 
20 titlecanbegintoain. The initlatactivatons created with a short lifespan, e.g., 
finally, when the initiar activator is about to fexpire, the SCbP 
Launcher and requests that the CAS refresh the activator. On the first refresh of the 
activator, CASLIB32 again provides the Launch String arid this time the CAS will 
: settle the transaction with the eCommerce server. Delaying settlement of thfe 

; 25 transafetlori allows the SCDP system to positively guaraint^iB that the tide ha^ mn 
v^^^^^ P 

The SCDP system supports five diffeirerit purchase models. The firet 
putehase model. Title SubMptions offere uhlm^^ 
; . specified pferiod of firtfe. Subscriptions (^^^ TTie second purchase 

30 model, Pacl«ge Subscriptfons such as iari "Arcade Game Pack", offers unlimited 
access to a set of multiple titiiBs for a lirn|ted time. The s^^ 
package subscription could change over time. F=or example, if the user purchases a 
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subscription to the "Hot New Games Pack", the titles available under this package 
may not be the same a week or two after the initial subscription purchase. The third 
purchase model, Pay Per Use, offers access once for an unlimited amount of time. 
In the fourth purchase modeh Tihife-Based Billing, a user is charged more for running 
5 the title for longer or can buy a fixed block of time: In the fifth purchase model, 
Monthly Billing, the SCDP system is integrated into an existing cable Multiple Server 
Operation (MSO) or telco billing system and adds charges to the customer's monthly 
bill. Additional purchase models can be added with minor changes. 

10 Virtual Store Front 

The Virtual Store Front server 215 and accompanying database 213 present a 
virtual catalog to clients and prospective clients of the SCDP system 200. In the 
illustrative embodiment, server 215 may be implemented as a conventional web 
server, e.g.. a iserver application executirig on top of arl operating system which, in 
15 turn, executes on top of a server hardware, similar to those described with reference 
to eComrnerce server 202; The store front application includes a graphic user 
interface which preseints a series of selection^ fdr clients to brdWse with a 
conventional rietwori< browser. Such selections may ineludie the name of a particular 
title, a brief description of the titlOi associated costs or purchase options, iri the event 
. 20 of a nriultlmedia title, such as a movie or audfo dip, brief samples of the title content, 
etc. In addition, associated with each title selection is a corresponding URN. As 
such, the store front implements the appropriate databa^^^ 
interact with datablis6 213 on Whiph^^^^t^^^^ digjitial 6ff6r, and 

; URIsJ mfomatiori irhay be st^ vi^iri the SiCDP' 

25 system i20d. In r^ : 
Ibgic queries database 213 foHh^ 
information to eCbmmerc^ ser^^^^^ 

In the illustrative embbdirnent, virtual istdire front server 21 5 and database 21 3 
are coupled to cache^^^^ 
30 previously described; It will be obyibus, hbwiever, to those reasonably skilled in the 
. ^rt that the SCDP system 200 may be implemented with one or niore virtual store 
fronts coupled to the cache server 210 and the eidonimerce server 202 over other 
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than a local area network, for instance a global area network; such as the Internet In 
a Planner reasonably understood by those skilled in In such 

implementiatiohs, where the storefront server reiskJ^ on a public network, various 
subsets of infpmiattoh may be available for Viewing by perspective clients. For 

5 instanoB, clients who pay a subscription fee niay haye access to a storefront server 
on the private networic whfch may provide greater infortnation and/or samples of title 
data then the general publk: accessing a store front server lobated on a public 
networit which may provide only minimal inforaiation regarding a title and its 
associated purchase options. 

10 ' . 

Briq Format 

Fig. 12 illustrates conceptually a block diagram of a briq in accordance with 
the present invention and its constituent components. As illustrated , a briq 1 200 
bomprises a briq header 1202. a cryptoblock 1204, a superijipck 1206 and one or 

15 more titles 1208A-1208N. The briq header 1202 contains infomiation used by the 
launcher module within the SCDP client, including such information as system 
registration infonnation. resolution, application title, a URL, etc. The cryptographic 
block 1204 is used by the ARFSD VxD within the SCDP client to detentiin^ if the title 
is encrypted, and, if so, the cryptographic key version used for such ehcryption. The 

20 supert)lock 1 206 may include general information about the briq including the size of 
the briq, the creation date, the entry in which the ROOT directory may be found, etc. 
Each of the titles 1208A-N may include a directory arid one or more files associated 
with a particular title. As explained hereinafter, briqs are stored bri the RAFT Server, 
accessed remotely by an SDCP client using the RAFT protocol, and presented to the ■ [ 

25 host's operating system as a local file syistem. 

In accordance with the present invention* one or riibre tities are processed 
arid packaged in the forni of a bricj. as described viith reference to Fig. 12. The 
process by which a titie is fonriatted into a briq is as follows. Firet. a utility tool, such 
: es the viewer utility in ttie Windows operabrig Systerh is used to extract registry 

30 irifbmiatiori from a title: Such registry entiles nlay comprise a rriiriimai set of 
irifbmr^tion such as the file riarhes, directory nam^s and configuratiorts cKings 
necessary to execute a particular title. The extracted registoy entries are placed into 
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a file. Next, the file containing the registry entries are provided to a creator program. 
The creator program, in the illustrative embodiment, comprises code capable of 
taking the data comprising the title and the registry entry file and encrypting such 
infbnnation in accordance with any number of cun-ently available encryption 

5 algorithms, the resulting encrypted files may be stored in a conventional directory 
hierarchy, as illustrated by directories 1208A-N of Fig. 12. Next, the root directory of 
the file system and any additional meta infonnation including the size of the file 
system, etc., are stored in the superblock 206 of the briq 1200, as illustrated in Fig. 
12. Next, information abdut the deciyption key. necessary to decrypt the encry^^ 

10 infbrttiation within the briq, is stored in the cryptoblock 1204. The infonnation within = 
the cryptoblock may comprise data identifying the key version and a description of 
the type of encryption used. The information in cryptoblock 1204 may be partially 
encrypted. Infomnation such as the briq URL, and system requirements are placed 
into the briq header 1202 along with the names of the executable files and titles, and 

15 a map of the network drive and additional tags. The infomiation contained within 
briq header 1202 is not encrypted, as illustrated in Fig. 12. 

Activator 

The activator has a fontiatais illustrated in Fig. 13. Spedfically, an activator 
2b 1300 comprises a token 1302. authorization data 1304i a cryptographic key 1306; 
aridibptiondly. one or more byte codes 1308-1312^^ In the illustrative embodiment, 
token 130i may be implemented similar RAH" token 800. as des 
\ j; ;. referencei to fig. 8 herein. AuthoriMtibn date 13^ comprises the "keep-alive" 

; / , 2 5 - 6^^^ 

cckI^ or, altematiyely. ma^ 

hash bf data previously assdciaited with the client. Key 3()6 comprises cryptographic 
;. data useful in decrypting the data o)^ The 
:•■ • ^^Wraphicdatacbrn^^ 

So by byte code irrterpreter 308 ahd supplied to the RAFT VxD to facilitate decryption of 
. briqdata. ". • ■ 
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in a simple,embodiment, actlvatop 1 30a comprises only token 1 302. 
authbriiatlbn data isck and key 1306. In a more sophi^ted embodiment, one or 
more byte codes 1308-1312 arie alsto included as partpf the activator. In the 
illustrative embodiment, byte codes are essentially instmctions executable on either 
a physical or virtual mabhine, as Implemented within the byte code Interpreter 308. 
In the illustrative embodiment, byte code interpreter 308 comprises a virtual machine 
capable of executing such byte codes as supplied to It from the afclivsitor. The type 
and nature of possible byte codes 1-N which may tte usisd With activator 1300 are 
described hereafter. Byte code interpreter 308 is described with reference to Fig. 

3C. ■ :,y^- 

Code Obfuscation 

The essence of a program can be broken up into flow and primitives. 
Nonrially flow includes building up higher level abstractions out of primitives. 
15 Optimization involves coml)ining redUndiaht primitives, reananging flow so similar 
struclbres can be tombinjed &ndellihiriated,^ 
tfiem with other, jfk)re efficient ^^^^^ 
progrSiiH with respect 
produce rrtore than dne oOrte*tresult^^ R^^ 
20 or somie subset of conredvariarits in p^riilel riiay be iiribre efficient overall, at some 
cost to the individual pifbductldh. 

Geiierically, optimization involves loold^^ 
problem and rhbdity it to p»i6^ In compilation specifically, it 

: ;' Ibvel code 

Pessimizatiott also preserves this cibnec^iess. But sacrifices e^^ / 
de{k)rtfpildtibii di^^ 
. By splitUng front end a^^^ 
. : diffbrenrt ibvels brid ^ows 

30 Lisp/Schieme) which provide for more flexibility^ Anumberof 
pessimizer techniques may be utilized with th6 present invention, including 1) 
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Assembler-level Peephole Pessimizer whieh takes bytecode streams and does local 
reordering and obfuscation; 2) Intentiediate Language Pessimizer which exposes 
the translation layer between the high level language and the assembler in order to 
provide a more natural interface for certain structural pessimizations; and 3) High- 
5 level Manual Pessimizer which, rather thdn actually performing generic operations 
on high lever language code, allows the coder to specify multiple ways of expressing 
a given function aind then have the compiler directly produce a form with 
combinatoric expansion of altematives already initiated. 

In theory, it is always possible for someone to single step the activator and 

10 monitor the changes it makes and thus figure out how to decode the briq, or even 
more simply, to stop once the briq is decoded and dump the cleartext out of memory. 
By using differing bytecode sequences, written in a hard-to-interpret "obfuscated" 
manner, and avoiding reusing identical ones, e.g. skeleton keys, the present 
invention utilizes constructs which make the work of the human decompiler hard, and 

15 the automatic analysis impossible. The bytecode makes the an unauthorized 

cracker's work on a single download arbitrarily time consuming, and not applicable to 
any other download. 

Sample obfuscation techniques useful with the activators of the present invention 
may include 

20 • Selecting from a large pool of algorithnfis for each operation so that even a 
second request for the same object gets significantly different code; 

• Apply behaviour-presenting operations directly to the byte code, using 
. \ ; pompiler^^ 

Have th^ SCpP client sapppil^m^^ byte codes, or cryptbgraphlcally 

: /25 ; ; key the byte code liit itself. ^ ^ 

• Self-modifying byte code. 

• "triapdoor" byte code streams, e.g. generating a sequence of bytecodes, and a 
niapping function that picks out a subset and maps the bytecode subject into 
a useful algorithm. It may be necessary to define constraints and then search 

30 a space for useful sequences. 

• "Dead code" bytecodes, possibly related by pattern to existing codes as a 
distraction. 
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• "abstain from" certain bytecodes. e.g., code has different meanings on 
subsequent runs. (High level tools caii sinfiply interleave working algorithms to 
produce these. Extensions Indude abstaining from any instruction which 
references a pdrticajlar location ot^ reg^ 

• "unary" opeifators for use in ofyptd ittiiaer^^ 

• Optimize the byte code rnappirig based on parameters of the code, e.g., 
frequency of use, unrelated factors, etc. 

• When iiiiplementing crypto directly in bytecode, deliver partial key/schedules 
or code sequences to generate l<eys instead of "standard" format keys. 

• Have the byte code download additional bytecode through later callbacks, or 
have the server send down byte code changes asynchronously. 

• Use existing environmental data as sources of byte codes, data, keying 
material, or weak entropy, such as the briq itself, or other binaries in the 
Environment, or even the downloaded bytecode. 

Ideally^ obfuscations may be produced into a framework that provides infomiation 
about how they can be combined vyith each other, and how they can be operated 
updri. 

Techniques 

Another way to give Activaitdrs additioifial Stre^^^^^ 
incomplete, so that they need to makis further contact with the CAS to coritinue 
operating. A 'Technique" is a piece of ojde that runs in the CAS and is customized 
to support such requests. Although rnultiple t^bhriiques could may be used, a single 
Technique ma^ implementation rah 

fad hairel CtiidiKJ into the CAiS, dr. a^^ dyniamicaiiy loaded 

bytecdde or shared objecb. the activator to Technique protocol may be a layer on 
top of an existing RPC for transpdrt fitirn the SCDP dient. eliminating the need for 
the technique to have predefined messages. In the present Invention, activator 
bytecode and Tefehnique bytecode may be treatecl as distlhct languages. Tedinique 
code may instead simply have single bytedbde^ for entire cryptographic routines. 

In order to implemartt obfuscated bytecbd 
invention, the fbltowing components sire utilized: 1 ) bytecode interpreter. 2) a bytecode 
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assembler; 3) cryptographic bytecode routines; 4) an Interliace to the ARFS VxD to call in 
to the activator at useful points; 5) protocol as decsribiBd herein which enables the 
activator to communicate with the tedinique Implementation in the CAS; 6) CAS 
Activator construction funcHons (activator factory 71 0); 

5 The reader will appreciate that the inventive system described herein 

facilitates the on deniand delivery of secure content over broadband networks as 
Well as private intranets. 

The above-described Invention rnay be implemented in either all software, all 
hardware, or a combination of hardware and software, including program code 
10 storied in fimiware fomnat to support dedicated hardware. A software rrtiplementation 
of the above described embodiment(s) may comprise a series of computer 
instructions either fixed on a tangible medium. sUch as a computer readable media, 
e.g. diskette 142, CD-ROM 147, ROM 115, or fixed disk 152 of Figure 1. or 
transmittable to a computer system in a carrier wave, via a modem or other interface 
15 device, such as communications adapter 190 cbriheded to the networic 195 over a 
miedium 191. Medium 191 can be either a tangible medium, including but not limited 
to optical or arialbg communications lines, or may be implemented with wireless 
techhiques, including but not limited to micrbWave, infrared or other transmission 
techniques. The series of computer ihstaictions whether contained in a tangible 
20 medium or a carrier wave embodies all or part of the fiinctionality prevfously 

described herein with respect to the inv^htibn. Those skiliied in tbb art will appreciate 
that such computerinstructions can be written in a nurifiber of programming 
languages for us^ with many computer architectures or operating systems and may 
; ^xist iri ni^hine executable fom^ usirig 
is anyrneriibrytechhdlogy,^p^^ / ■ ; ^ 

sfemiconductbr, magnetic, b or other mefrtdj^^ transrnitted usir)^ arty 

rommahicatioris technology, present Or ftiturB; includiri but not lirnited to optical, 
. infrared, riiicrowave, or other trarismissibri tebhhbbgie^ It is contemplated that such 
. a (WDthputer prbgiram produd may bfe dls^^^^ iis: a reifndvable niedia vi^ith 
30 accompjartying printed br felectrohic dodjment^^^^^ e^ g., shrink whipped software, 
preloaded with a computer systern. e.g.. on system FROM or fixed disk, or distributed 
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from a server or ieiectronic bulletin Board oVer a network, e,g., the Internet or World 
Wide Web. 

Although various exemplary eitibodiments of the invention have been 
disclosed, it will b& apparent to those skilled in the art that various changes and 
5 modifications can be made vyhich wilj achieves scMrife of the advantages of the 
invention WiUibutdeparling from m sfjirit and sbopfe of the Inven^otr. It will be 
obvious to those reasonably skilled in the art that other components perfdrming the 
s3me functions may be suitably substituted. Further^ the methods of the Inveritibn 
hiay be a(rfiieved in eitWall sofhvare irtiplelTiehte^^^ 
10 prodsssor instructions, or in hybrid ImpliBrtientatibh^ which Utilize a cornbiriation of 
hardware togic and software togic to achievis the same results. 

What is claimed is: 
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1 1. 

2 of: 



A method for securely delivering contertt over a network comprising the steps 



3 (a) storing at least one title on a content server operatively coupled to the 

4 network; the title stored in uh^^ 

5 (b) storing on ah access Server operatively coupled to the networi< a 

6 location identifier of the title and data necessary to process the title into 

7 executaWe fbrhi; 

s (c) requiring a client process operatively coupled to the network to obtain 

9 the location identifier of the title fr^om the access sen/er prior to 

10 retrieving at least a portion of the title from the content server; and 

11 (d) requiring a client process to obtain from the access sen/er the data 
.''2 necessary to process the portion of the title into executable form. 

1 2. The method of claim 1 further comprising the step of: 

2 ('^) : requiring the client prbcess to 

3 and to present the signature to the content se^^^^ 
^ least a portion of the title from the content server. 

1 3. The method of claim 1 further comprising the step of: 

2 (e) requiring the client process to obtain from the access server time data 

3 defining a time period in which the client proceiss may retrieve at 1^^^^ 

^ ; seh(^r^^ arid before retrieving at least a 

1 5. Ah apparatus for secure delivery o^^^^ 

2 (a) a content server operatiyely cbupled to the netwdrt^ and having at least 

3 one title stored therein unexecutable forrn; 
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1 (b) an access server operatively coupled to the network and having stored 

2 therein a location identifier of the title and data necessary to process the 

3 title into executable form; arid 

4 (c) a client system operatively coupled to the network and containing program 

5 logic configured to obtain from the access server the location ideritifier of 

6 the title and the data nedes^ary to process the portion of the title into 

7 executable form. 

1 6. The apparatus of claim 5 whisreih the client sys^^ 

2 prbgtem logic configured to execute ^p^^^^ 

1 7. The apparatus of claim 5 whtirein the access server further comprises: 

2 program logic configured to generate time data defining a time period in which 

3 the client system may retrieve at least a portion of the title from the content server. 

1 8. The apparatus of ciairn 7 Wherein the dienf system further comprises: 

2 program logic configu red to request new time data from the access server 

3 once the time period has expired. 

1 9. The apparatus of claim 5 wherein the network comprises a broadband access 

2 network. 

1 10; V Apparatus for secure delivery of content over a network cdifriprising: 

2 (A) content server system connectable to the network, the content 

3 server system comprising: > 

. 4 (A.1) auth^nilcatei p^ 

5 received firom a citent procesis, the tokeh containing data identifying a 

6 ; time period, arid corifig^^^ 

7 authorized to access the memory at a specific time; and 
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1 (A.2) access program logic, responsive to the token received 

2 from the client process, the token containing data uniquely identifying 

3 one ofthetjtles stored in thennemory, and configured to enable access 
^ to the memory and the title uniquely identified by the token; 

5 (B) access server system connectable to the network, the access 

6 server system comprising: 

7 (B.1) conversion program logic, responsive to a unique 

8 identifier of a title supplied by a client process, and configured to 

9 convert the unique identifier of the title into a location identifier 

^ 0 indicating an address on the network where the title may be accessed; 

11 and 

12 (B.2) activator generation program logic, responsive to a 

13 request from a client process, and configured to generate an activator 

14 in response thereto; and 

15 (C) . client system connectable to the content server system and the 
1S V ^c^^^ss ^^'^^r system over the networi^^ 

17 comprising: 

18 (C.I ) program logic configured to obtain from the access server 

19 system a token, an activator and a location identifier of the content 

20 server at which an identified title can be accessed; 

21 (C.2) program logiccohfigured to retrieve at least a portion of 

22 the identified title from the conteM 

(C.3)prdgranT logic iro^ 

24 : ^^v; 'i^ 



1 ' the apparatus of cte^^ 

2 dperatihg system executable oh the client system and wherein the client process 

3 further domprises: 

4 (C.4) program Idigic configured to nriount a network file system 

5 assbciated with the Identified tiUe and store in the memory of the client system, a 

6 plurality of registry entries related to^^ t^^^^^ 
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1 (C,5) program logic c»rifigured to intercept fe^ 

2 operating system during title execution and redirect selected of the intercepted 

3 request to the set of registry entries. 

1 12. The apparatus of claim 10 wherein the activator comprises cryptographic 

2 data. 

1 13. The apparatus of claim 10 wherein the activS^^^ 

2 bytecode and the dient system further comprises: 

3 (C.4) program logic configured to interpret and execute the 

4 bytecode contained within the activator. 

1 14. A method for executing an application on a local computer system without the 

2 application being installed on the local computer system, the method comprising the 

3 steps of: 

4 (a) accessing a network mouhtable file system arid set of registry entries 

5 related to the application; 

6 (b) mounting the network file system; 

7 (c) storing the registry entries on the local computer system; 

8 (d) retrieving at least a portion ofthe application from a remote source; 

9 (e) executing the application under the control of an operating system dh the 

10 local computer system; 
"■■r-:. :'^''.:;:^^, . (0 intercepting requests from 

-/ ■;■ ■ to redirecting selected of thfe ihtbrc^ entries 
; 

1 15. In a computer system having a process^^^ a memory and ah operating 

2 systerh capable of executing one or more applications, an apparatus for executing 
: 3 an application without installing the application on the computer system, the 

4 sipparatus comprising: 

5 program logic configured to mount a riietwortc file systerii and store in the 

6 memory a plurality of registry entries i-elated to the application; 
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1 program logic configured to. execute at least a portion of the application retrieved 

2 from a remote source; and 

3 program logic, responsive to requests from the operating system, and 

4 configured to intercept requests from the operating system and redirect selected of 

5 the intercepted requests to the set of registiy entries. 

1 16: In a client process executing 6n a locar computer system operatively coupled 

2 over a computer rietwori^ to an access server and one or nibre sources of title data, 

3 a method for enabling on-demand delivery of a title comprising the steps of: 

4 (a) obtaining from the access server a token, an activator and a network 

5 addressof a source at which an identiified title can be accessed; 

6 (b) transmitting the token to the source, the token data defining an interval of 

7 time in which the source may be accessed; 

8 (c) retrieving at least a portion of the title from the sbutte; 

9 (d) executing the portion of the.title redeived from the source; and 

10 (e) obtaining from the access sfen/er a riefr^s^^^ 

1 17. The method of claim 9 wherein the tWe cbmprise^ a netvi/ork mountable file 

2 system and a set 6f registry entries and wherein step (d) cbfiiprises the steps oft 

3 V n^ouhting the netwbri< file systerri apd storing the registry entries; and 

4 d.2 Intercepting requests froni an operating system executing on the local 

5 computer systein and redirecting Selected of the intercepted requests to the registry 

6 entries: 




(bj converting a lihique identifier of a title received from a 
requeisting process to a location identifier Indicating an address on the computer 
rietwbric Where the title may be abcessed; 
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(c) generating an activator; and ; 
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1 (d) forwarding the activator to this irequesting process over the 

2 cortiputer network. 

1 19, In a server apparatus comprising a processor, memory and a network 

2 interface, the server apparatus connedtable to one or more client processes a 

3 computer network, a method comprising the steps oft 

4 (a) receiving a token frdrh a client process through the network interface, 

5 the token containing data identifying a time period and data uniquely identifying a 

6 title; 

1 (b) detentiining wh^thbr the client process is authorized to access the 

8 title at a specific time; 

9 (c) if the client is authorized in step (b). accessing the memory and a 

10 title uniquely identified by the token; and 

11 (d) supplying to the client at least a portion of the title identified by the 

12 token. 

1 20. The method for selectively enabling delivery of a title over a computer network 

2 to; one or more requestor processes comprising: 

3 (a) providing, under predetermined conditions, a requestor process with 

4 access to selected portions of a title, the title being stored at an address on the 

5 computer network in unexecutable form; 

6 (b) providing the requestor process with data useful in processing the title 

7 from unexecutable forrii to executable form; arid 
. 8 ; allowing executiorl of seled^^ 

• ^^ Isystern while 

1 21 . A method for delivering titles over a cortipuler network to one or more 

2 requestor processes comprisirig: 

3 (a) receiving from a requestor p 

4 (b) providing the requestbr process with data identifying 

5 computer hetworic where the title execufeibles rhay be accessed and authorizatioh 

6 data necessary to access the title; iand 
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